Date: Wed, 18 Jan 2012 11:32:18 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, Igor Mozolevsky <igor@hybrid-lab.co.uk>, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <alpine.BSF.2.00.1201181121010.51158@fledge.watson.org> In-Reply-To: <4F16900A.90905@FreeBSD.org> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <op.v78i3yxi34t2sn@tech304> <4F15C44F.1030208@freebsd.org> <1326836797.1669.234.camel@revolution.hippie.lan> <4F16019F.2060300@FreeBSD.org> <1326843399.1669.249.camel@revolution.hippie.lan> <4F160B99.1060001@FreeBSD.org> <CADWvR2jdeu6R%2BmX1n2Uz1WUBcZ=BKWSDB4nR-rEv_P4jAZg3HQ@mail.gmail.com> <4F16900A.90905@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Jan 2012, Andriy Gapon wrote: > on 18/01/2012 02:16 Igor Mozolevsky said the following: >> Seriously, WTF is the point of having a PR system that allows patches to be >> submitted??! When I submit a patch I fix *your* code (not yours personally, >> but you get my gist). > > Let me pretend that I don't get it. It is as much your code as it is mine > if you are a user of FreeBSD. I just happen to have a commit bit at this > point in time. > >> No other project requires a non-committer to be so ridiculously persistent >> in order to get a patch through. > > There are about 5000 open PRs for FreeBSD base system, maybe more. There are > only a few dozens of active FreeBSD developers. Maybe less for any given > particular point in time (as opposed to a period of time). And dealing with > PRs is not always exciting. Need I continue? > > P.S. Using GNATS for the PR database doesn't help either, in some technical > ways. The structural problem around the PR system for the base system is that there isn't a whole lot of incentive for most developers to use it. I think we can reasonably categorise developers into three classes -- some move between or span them, of course: (1) Volunteers. Due to childhood trauma, they have a desperate urge to write operating systems. Not much incentive to do PRs here, as most refer to versions of FreeBSD before their time, aren't great characterisations, rarely come with patches, and when they do, the patches are out of date, don't apply, have the wrong style, solve the wrong problem, etc. A sweeping generalisation, but you see what I mean. The only exceptions here are our dedicated team of bugmeisters, who get enourmous respect from me, but they are a tiny minority. (2) Employees. They work at a company using FreeBSD as a product, and effectively deliver their own CompanyBSD as a further product to their own internal customers -- to be put on a web service frontline, to ship as the foundation of an appliance, etc. The key phrase here is "internal customers" -- they have their own bug report database, which they respond to in a timely way due to the incentives of the workplace, but also because they are relevant bug reports for their product goals. (3) Authors of upstream code. They don't even work on FreeBSD, but their code ends up in FreeBSD, so they also have their own bug report databases, fix bugs, and eventually the fixes trickle into FreeBSD. With the above, the incentives to handle PRs are very weak -- and it's compounded by gnats being terrible for both submitters and handlers of bug reports. Contrast this with ports, where the PR database is a key part of the workflow. However, and I am being entirely honest when I say this: FreeBSD works anyway. So somehow, we end up with a pretty good OS despite largely ignoring our bug report database. Why? Well, for (1) it's because volunteers have a strong sense of ownership of the code they've written and care about, (2) there's a significant internal QA and bug management effort at downstream companies from FreeBSD, whose improvements are frequently upstreamed by committers on staff, and (3) occurs independently of bugs in our bug report database. Don't get me wrong: it's a problem that the PR database goes so unloved. But it's a symptom of the construction of *extremely large* volunteer projects in which the incentives are not aligned for dealing with PRs most of the time. If you want to see something similarly sad, try counting dropped patches on the linux-kernel list. Someone once ported the entire FreeBSD kernel audit framework and OpenBSM to Linux, posted on the list saying "here are my patches", never heard anything back, and went away. You can moralise in various ways and for various parties in that relationship, but at heart, that's pretty similar to a lot of the patches in the PR database; you'll find similar stuff in every open source project of scale. I submitted patches to fix several bugs in KDE a decade or so ago .. after five years, the reports were closed as "out of date". Yet large open source products *do* work, and become the foundations for amazing things. I think shifting away from Gnats would help as it would make it easier for developers to find bugs they care about, users to submit higher-quality reports, and so on. Gnats makes it really hard to manage reports in a useful way. Another possibility is to get some combination of {The FreeBSD Foundation, iX Systems, ...} to trawl the bug report database in a more official capacity. The problem there is that this will be a high burn-out job. I'll bring it up at the next Foundation board meeting, especially after a bumper year of fund-raising, and see what we can do. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201181121010.51158>