status?

[Lyndon Nerenberg]

> Admittedly so, I'll probably pull my hair out and scream if
> I need to look over each and every document in our tree and
> garbage collect 4.X stuff - updating and finishing parts as
> I can.

I think too much emphasis is place on the release the bug is reported  
against. Most userland bugs are independent of the release version.   
Yes, that's an anecdotal claim, but it's based on over two decades of  
fixing bugs in applications, kernels, and everything in between.

I think the problem boils down to the fact that the bug fixers mostly  
fall into two classes:

1) FreeBSD core, or close to it, and

2) Relatively inexperienced UNIX programmers who see bug whacking as  
a way to obtain knowledge through experience.

When you are the recipient of their efforts, it is very easy to  
classify them.  A category (1) bug buster says "no patch provided/ 
patch doesn't compile against current/style bugs/etc."  A category  
(2) bug buster says "is this still a problem" without even reading  
the bug report.  I exaggerate case (2) to a point, but only just.

Case (1) is understandable.  Those people are *busy* and will use  
whatever means at hand to filter out what they cannot immediately  
work on.  But the consequence of this is that anything not directly  
related to the vacuum-edge-of-space version of -current they won't  
touch.  Fair enough.

Case (2) is also understandable.  These tend to be people with little  
experience doing in-depth problem analysis, a lack of familiarity  
with the relevant standards, and an abundance of enthusiasm to help  
the project.  The latter draws them in, then the former scares the  
bejeezus out of them.

We need a category 1.5: people with both the time and experience to  
pick off a PR, spend some time reading and *understanding* the issue,  
and then proposing or applying a fix in the context of both the  
original PR and the current state of the release tree.  To fill this  
role you really need to be a generalist.  You must understand the  
whole UNIX philosophy, you need to understand the design goals of  
FreeBSD, have more than a basic familiarity of the relevant  
standards, and not be afraid to stand up and defend the decisions you  
make in the face of criticism from people who have a scary amount of  
knowledge.

These people exist.  So why can't we seem to get them on board.  My  
opinion is that the mentoring process to becoming a committer is too  
opaque.  And perhaps not granular enough, although that granularity  
is primarily dictated by the source code management system.   
Regardless, I have time and time again seen new people come on board  
wanting to whack bugs down, only to burn out within weeks, if not  
days.  Clearly there is something wrong with the process.  And it  
could be as simple as the project setting unreal expectations for the  
newcomers.  I don't have an answer for this.

> In the case of PRs (both code and doc), the process is much
> more in depth.  While I'd like to say "just close them and
> wait for another PR for 5/6/7" that is just bad handling.

And as an example, I will quote a biased example: bin/7868

7+ years and counting :-)

> So my opinion is just coming up with some kind of .plan for
> dealing with them.  It could as simple as play the normal
> reply asking about it, try to reproduce yourself, etc.

No!  This does not cut it.  The bug I reported was against the  
shipping release at the time.  The "cannot reproduce" reply was  
against the head -- something everyone is told not to consider  
production -- at the time when the release I reported against was  
what people were being told to run.  You don't get it both ways, and  
this is an attitude that has to be clobbered.

The argument about "we cannot support old releases" is a direct  
artifact from the people working on -head also trying to tackle most  
of the bugs; their idea of "old release" is anything prior to last  
week, and for them that's a reasonable argument.

Again, we come back to category 1.5.  We need to cultivate people  
with smarts who can address bugs in production releases.  We also  
need to cultivate the concept of MFS: merge from stable.  There is  
nothing heretical about transplanting fixes from 6.x to 7.x.  I  
firmly believe the reason we have very few 1.5s is because the 1s  
won't have anything to do with anything outside of today's p4 or  
cvs.  That has to stop.

> Guess what I mean is, damn, that's a huge project.  :(

No, the huge project is implementing a new bug tracking system.  What  
we have can't even accommodate MIME for cryin' out loud.  Searching  
is painful.  Task assignment (and tracking) is all-or-nothing.  As  
much as I loathe SQL, I'm ready to admit that we need something new  
built upon a relational database if we're going to move forward with  
any hope of keeping up (and doing a good job).

--lyndon

P.S.  I've made liberal use of the 'royal we' above.  I have no  
affiliation with the FreeBSD project, other than having been a  
(mostly :-) happy customer since the 1.5 release.