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-trackingWhen 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
Locked
