FreeBSD has serious problems with focus, longevity, and lifecycle

[Eitan Adler]

On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky <igor at hybrid-lab.co.uk> wrote:
> On 18 January 2012 01:11, Eitan Adler <lists at eitanadler.com> wrote:
>
>> It takes time to review and test patches. There are a lot of people
>> that think "it only takes 30 seconds to download the patch, apply, and
>> commit."  This is just not true.
>
> I fully understand that and it is not what I was saying, what I was
> saying was about the patches that were being plainly ignored/allowed
> to go stale. What you said below is perfectly reasonable once a
> committer is actively involved in dealing with a patch, then I, and
> anyone else for that matter, would be very reasonably expected to be
> involved in the process and understands that someone else is working
> on the issue you've address.

Often times people don't do this part and submit a "drive by patch."
Nothing is wrong with that, but it does make it harder to verify that
a fix is correct (especially for hardware support PRs).

> The problem, however, lies in the time
> between a patch is submitted and is "picked up", if the latter ever
> occurs!.. That is where the discouragement occurs.

I guess I didn't follow through on all the above. My point was that
who wants to spend 3, 4, 7, 10 hours fixing a bug report when they can
be working on a shiny new feature (or play games, or anything else but
work!)?

> I hope I've address what you say here just above :-) and
> wholeheartedly agree with everything else you've said, but you are
> addressing the problem from a different angle: nobody is ever going to
> disagree that _once_ someone has picked up a patch it will take them
> time to get it through whatever steps necessary.

As I said above, the time it takes to follow through on a PR
discourages people from even looking.

> But, as I said above,
> it's getting to *this* stage that is the lengthy and a disheartening
> process...

I agree that this is a real problem. Unfortunately I can't think of
any good solutions.
The bugbusting team maintains a list of "easy" and "quality" PRs which
we try to get committers to look at. I also maintain a personal
"bugging list" (pun intended) of PRs which I bug other people about.
This has helped somewhat (the PRs I bug people about tend to get
closed) but it isn't sufficient.

>> If you have ideas to make this process easier or more efficient we are
>> all eager to hear them. I am especially interested to know what *I*
>> could do to help speed things along in areas I don't know well enough
>> to commit to.
>
> The problem, which I suspect is very difficult to overcome in what I
> call the "bazaar" environment, is the enforcement.

Solving this and other problems is so hard a back has been written on
the topic: http://producingoss.com/

> One way to
> "encourage" people to fix their code would be to prevent them from
> committing to -CURRENT once they pass a certain threshold of
> "unattended" patches. Of course then, committers will be whinging that
> they'd be resigning if they can't commit to -CURRENT, but quite
> frankly, why should anyone have the commit privilege if they can't be
> bothered to address the bugs, are those people just using the FreeBSD
> project to boost their CV (with great powers comes great
> responsibility!)?

Wouldn't this discourage even more people from helping?

-- 
Eitan Adler