Re: Support for 5.x (Was: Re: What about BIND 9.3.4 in FreeBSD in base system ?)

On 03/02/07, Julian H. Stacey <jhs@xxxxxxxxxxxxxxxx> 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
Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz.
Vista of a Bill from Redmond ?
freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

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
using nforce4.

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.

freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Support for 5.x (Was: Re: What about BIND 9.3.4 in FreeBSD in base system ?)
    ... volunteers processing community inputs. ... Handling other people's send-pr bug input would be boring ... I've filed some send-pr diffs years back & not seen action, ...
  • RE: Anthonys drive issues.Re: ssh password delay
    ... The dmesg you sent indicated that the 2 disks were negotiating at ... > possible cause in the universe before blaming it on FreeBSD. ... to take the risk of it being hardware, ... believe is that it's a bug in the FreeBSD driver. ...
  • Re: What do you dislike about OSX?
    ... is is when you claim that OS X is derivative of FreeBSD. ... about *other people* not needing to have all windows visible at all times. ... Most end users don't even know the bug exists. ... offer reasons for me to change my mind. ...
  • Re: Do we need this junk?
    ... I have an 1742A if any developer needs it for bug chasing. ... It's a full length card. ... To counter Nikolas' `stats' argument to abandon much hardware support: ... There's scanners with FreeBSD embedded inside: ...
  • cvs-src summary for November 8-15
    ... It is intended to help the FreeBSD community keep up with the fast-paced ... You can get old summaries, and an HTML version of this one, at ... sf driver gets polling and ALTQ support ... Xin Li committed a fix to pppd, the PPP daemon, to a bug ...