Hi, Carlin Bingham wrote on Tue, Jun 20, 2017 at 11:20:10PM +1200: > On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote:
>> would it be possible to establish a real bug tracking system for >> OpenBSD? Something with bug owner, severity, attachments, assignee, >> and (very important) some reliable response time and a databse >> to search for known problems? > There was a GSOC project proposed for this in 2014 but it apparently > didn't get any takers. It had fairly clear requirements: > > "A bug tracking system that integrates with sendbug(1) and doesn't suck > dead bunnies through bent straws." > > https://web.archive.org/web/20140303013316/http://www.openbsdfoundation.org/gsoc2014.html#bug-tracking When i read those sentences back then, i instantly wondered how a GSOC project might help with the maintenance task. While a few GSOC projects do produce useful code (my subjective impression being that far more fail completely), even those few that succeed are notorious for causing substantial workload for developers - both for the paperworks with Google and to get the code into the tree. The most common reason for failure is that even though some interesting code does get written, it never gets hammered into shape sufficiently for commit. The GSOC student often cannot do it due to lack of skill and experience, and also due to lack of time after the end of the summer; the mentoring developers are often overwhelmed with the amount of work required: getting good and "almost ready" code *really* ready for commit is often much more work than people unfamiliar with OpenBSD development would believe. Getting from "almost ready" to "ready" can be more work than getting from "nothing" to "almost ready". As a drastic example, converting apropos(1) from dbopen(3) to SQLite3 took Kristaps a few weeks to get it almost ready, and after that it took me a year to get it ready and committed. The most successful OpenBSD GSOC project ever, mandoc -Tps, reduced the workload by having the paperwork done by NetBSD, and i only had to do seven commits in the time from June 10 to July 31, 2010, without having to tweak the code because it was so good, and which i didn't even need OKs for, so it barely caused any work at all. That was not at all typical to a very unusual degree. But yet, long-term maintenance of the -Tps and -Tpdf code was both seriously neglected (not a huge problem because it is not exactly business- critical functionality) and it did cause some maintenance work for me now and then (not so much that it even became a problem, but it was noticeable at some points). So, while GSOC might have occasional benefits, - it definitely never reduces the workload for existing developers, quite to the contrary - it has an extremely low efficiency in bringing in new developers (even though that does happen in rare, exceptional cases) - it rarely results in code that matures enough to get used in practice (even though that does happen in a few cases) - i'm not aware of a single example where it resulted in viable long-term project infrastructure Yours, Ingo
