segmentation fault freeradius 2.1.7 using rlm_sql

[Bjørn Mork]

John Dennis <jdennis at redhat.com> writes:

> * FreeRADIUS has way too much churn for a critical system
> service. Think about other system services, how often do you see
> kerberos, bind, iptables, pam, MySQL, etc. going through significant
> revisions? Are the administrators of those services constantly being
> told to upgrade the service because of the bug/feature du jour?

I think that's unfair.  All of the other services you mention have their
share of release related problems.  The details are too off-topic on
this list, but things like having "iptables" completely pulled out and
replaced every now-and-then (remember ipchains?  Heard of nftables?)
springs to mind.  Or the wait-forever-for-a-new-stable-release of MySQL.

And, although I haven't verified this, I'd be surprised if the RedHat
packaged versions of all those services didn't include quite a few
bug-fixing patches.  There is no such thing as a bugfree release.

> * The QE component of FreeRADIUS has proven to be inadequate. I know
> Alan runs a set of tests and he calls for testing prior to a new
> release. But we've seen the amount of testing which actually occurs is
> inadequate because releases have gone out with significant problems
> and those releases have gotten pushed into production. I think part of
> the problem is the frequent release schedule (measured in months) and
> the lack of a coordinated beta testing program. Releases should not
> occur until after they've successfully navigated a beta program.
>
> I humbly would suggest the following:
>
> * Create and maintain a "stable" version.
>
> * Organize a rigorous beta test program.

I guess no one is going to _oppose_ those suggestions. 

But both of them are kind of already there.  You do have branches which
are supposed to be stable.  And you do have the call for testing you
mention.  The reason this is inadequate is probably lack of man power.
How many users do actually test the proposed new release on a (near)
production system?  Not nearly enough, as shown by the bug reports
coming in right after a release.  Myself, I usually build and install
such beta versions on our test system, but we do not really have a
complete lab with hundreds of different big NASes and millions of real
users. Some problems never show up before we put it on a real production
server.  Which is kind-of hard to get accepted for a beta test.

The FreeRADIUS user mass is probably too low to get anything close to
real testing without doing an actual release.  Which brings us to the
next point:

> * Slow down the release schedule, avoid the temptation to cut a new
> release because of minor new features. If production servers can't run
> successfully without a feature that's an indication the prior release
> was too hasty. Critical bug fixes should occur in the release branch
> and the release branch re-released. The release interval for a system
> service like FreeRADIUS should be measured in years, not months or
> weeks.

I don't thing the 2.1.x history looks too bad. Except for a couple of
extra bugfix releases early in the cycle, it's been 3-4-5 months between
them: 

release_2_1_0:  2008-09-05 15:27:57 +0200
release_2_1_1:  2008-09-25 10:41:26 +0200
release_2_1_2:  2008-12-04 10:50:29 +0100
release_2_1_3:  2008-12-05 17:37:56 +0100
release_2_1_4:  2009-03-11 03:26:50 +0100
release_2_1_6:  2009-05-18 13:12:54 +0200
release_2_1_7:  2009-09-14 16:43:29 +0200
release_2_1_8:  2009-12-30 16:44:35 +0100
release_2_1_9:  2010-05-24 07:40:58 +0200
release_2_1_10: 2010-09-28 13:03:56 +0200
release_2_1_11: 2011-06-20 16:57:14 +0200

> Comments? Thoughts? Do you agree/disagree?

I don't think discussing strategies is very useful given the obvious
lack of contributions to the project.  It's not like there are resources
which could/should be (re)allocated anywhere.  All available resources
are already used in an extremely efficient way. There are just too few
of them to do all that you want.

But the project could most certainly need more contributors.  Why not
create and maintain a stable branch, like the stable kernel branches?
Like the kernel, I don't think that's really a job for the main
developer(s). It's more of a janitor job.

Or why not improve documentation?  The new Wiki opens possibilities for
anyone to contribute again.

And for beta testing: It's pretty obvious that the most important
missing part are the testers.  Bring them in.

The positions are open... In my experience the FreeRADIUS project has
never ever turned down any offer to help.  A simple task, which doesn't
even require any longterm commitment, is just squashing a few bugs the
next time there is a call for testing.

Just my humble thoughts, as a fellow FreeRADIUS user.  


Bjørn