status?

[Remko Lodder]

Lyndon Nerenberg wrote:
>> 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 am not sure whether you are following the PR tickets and the hunt
to make sure something useful can be done with them. We (the bugbusters)
are looking over the hedge, not restricted to "reported against 3.2
this no longer lives", if you have seem my feedback requests most of
them imply: Is this still a relevant problem on recent FreeBSD versions?
Obviously we are not going to fix a 3.2 anymore, but we might be able
to resolve  this on newer FreeBSD releases.

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

Yes and that is needed because there is too little manpower to keep up
with the incoming flood of PR's. If all the bugbusters would continuesly
try to reproduce things (most likely they dont even have the hardware
for this), we would effectively stop working on PR's at all. The 
submitter most likely has the hardware and most of the time they are
happy to see whether the problem is still there on a more recent
version of FreeBSD.

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

So, I see you going out on the streets, selecting these 1.5 people for
us and then you and those 1.5 people you are talking about are going to
help us out. Snap out of it, the world isn't as simple as that. If that
were the case we would have had a couple of more of those people 
already. What we need is a group of people monitoring incoming tickets
and they dont -have- to be programmers or something, they can just
be the first filters and make sure that useful information is included
in the tickets at all. Then they can assign it to someone who is active
in the region the PR ticket was filed against and try to make sure that
a follow-up etc is to be reached.


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

Again: You appear to have a can of these people, mind popping it open so
that we can use them? It's interesting to see that you are clearly 
stating that our processes are wrong, but then dont have an opinion on
how to solve this. If your statements are that strong you would have
come up with a better idea, instead you are being negative and are not
producing alternatives.

> 
>> 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 :-)

Yes, it seems that people were not interested enough and continued
their lives and other code. It happends from time to time, and in
a all volunteer project the 'other party' has to live with that.

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

You are clobbered about your specific PR ticket. The idea of Tom is good
and is mostly followed by bugbusters, if the reply of a bugbuster isn't
good enough for you, then reply, but always remember that we are 
volunteers trying to help eachother out. There is no way one can claim
that something needs to be done right now. You can only make that happen
by having paid support from someone who is allround enough to fix these
sort of things.

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

It is not an artifact, it is real life for us, there is not enough 
manpower so we are not pretending we can keep supporting older releases.
Again the only thing that would resolve this is by having paid support
to get these things done.

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

I see you are volunteering to help? Please look into the list of
open tickets and help us resolve them. We await your feedback on
that.

> 
>> 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).

My goal was not to discuss our current bugticketing system but to get
people to help me and the other bugbusters.

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

Now that's at least one happy camper ;)

Now, my reply seems a bit grumpy (yes I have stated this before
in another post), my idea was overlooked in this email and I only
ask for something simple: hunt down the older tickets, are they
still relevant? Update the information in the tickets so that we
can -try- to resolve them.

Thanks.
-- 
Kind regards,

      Remko Lodder               ** remko at elvandar.org
      FreeBSD                    ** remko at FreeBSD.org

      /* Quis custodiet ipsos custodes */