Support for 5.x (Was: Re: What about BIND 9.3.4 in FreeBSD in
base system ?)
chrcoluk at gmail.com
Tue Feb 6 13:49:59 UTC 2007
On 03/02/07, Julian H. Stacey <jhs at flat.berklix.net> wrote:
> > It seems to me, the one reason for limited resources is - project has
> > no resources to accept resources. I can't tell why the project lack
> > volunteers processing community inputs. May be, there are no such
> > As I don't know what's wrong nor how to correct it, this message is not
> > complaint in any way. It's just a note related to Doug's notice ...
> [ I wonder if for the thread, per
> bugs@ or bugbusters@ might be better ? Not on those though .. ]
> Nice definition: "No resources to accept resources" :-)
> Handling other people's send-pr bug input would be boring
> compared with writing own code, or debugging. Hence unactioned send-prs.
> I've filed some send-pr diffs years back & not seen action, others
> have been actioned occasionaly & I've been guilty of not responding
> in time (Mea Culpa, even own bug reports are boring, especially
> since once my auto diff applier works for me, there's less incentive
> to persuade send-pr team to apply diff). Probably a common phenomena.
> Dealing with boring bugs surely approaches paid work in needing
> motivation, so if the FreeBSD Foundation (a member cc'd) ever has spare
> money, it may be wise to have a few people paid something to action the
> oldest=most boring send-prs ?
> Oldest often would mean "So boring no one has touched it, (Or so
> intractable/ insoluble/ major dev. effort required)". If we used
> any other criteria than oldest first, it would need someone to spend
> time judging what should be paid as most boring & what not, & then
> we'd be in a recursive "Woulndn't that be a boring job too?" so who
> would do That ? So oldest bug first, unless reason to skip, eg
> If companies ever want to sponsor a little, we could suggest to
> companies: please sponsor one of you own staff members (or some
> freelance FreeBSD commiter), perhaps eg one day a week or just
> Friday afternoons or whenever panic requirements are lesss likely),
> to work the oldest = most boring send-prs that have been _so_ boring
> for years no one has processed them.
> The method of oldest most boring first would not destroy the incentive
> of the code bug-a-thon people to periodically attack the parts of
> the send-pr backlog they consider newer & interesting enough to
> work on unpaid.
> Disclaimer: Yes I'm a freelance. But no commit privs, so not eligable.
> Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com
> Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz.
> Vista of a Bill from Redmond ? http://berklix.com/free-talk-on-free-software/
> freebsd-security at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
think you hit the nail bang on the head, I am one such person who
tried to submit a bug causing crashes and have found a lack of
enthusiasm to get the bug fixed. One thing I have noticed about 6.x
is there is many features that 5.x doesnt have, so it looks clear
there is lots of activity in working on new code but little activity
in fixing bugs and working on stability.
Example I can give is I noticed freebsd 5.4 has limited support for
nforce 4 ide, this is year 2005 code, and there was a patch to
complete the support so sata was supported. Checking the same src
file on freebsd 6.2 has all references to nforce 4 removed, the patch
was apperently close to been commited to 6-current at the time so I
can only guess that they got bored of trying to make it stable so
simply removed the code to not delay 6.0 release and this explains why
my hardware works better in 5.x then 6.x on this particular server
In general I have noticed a decline in robustness and stability as
freebsd release numbers go up, freebsd 4.x was very stable and its not
hard to see why people refuse to move from it, 5.x was somewhat less
robust but I think 5.x is more stable then 6.x, 6.x appears to have
some compatbility problems with hardware and is more picky with what
hardware it works well with.
If support is planning to be dropped to 5.x early in its life (only at
.5 release) then it is dissapointing and a sign that there is no
motivation to work on old code and old bugs. I wonder if a paypal
slush fund where people who use freebsd can donate to and this slush
fund is then used to pay devs who fix pr's oldest first of course
would be effective.
More information about the freebsd-security