Hi folks,
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? Currently I have the impression that you have to be very lucky to be recognized on [hidden email]. This is highly frustrating and discouraging. Regards Harri |
Am 19.06.2017 18:51 schrieb Harald Dunkel:
> some reliable response time I've to decide between popcorn and other stuff with flames. -- pb |
In reply to this post by Harald Dunkel-5
Hi,
Harald Dunkel wrote on Mon, Jun 19, 2017 at 06:51:24PM +0200: > would it be possible to establish a real bug tracking system > for OpenBSD? There is exactly one reason it hasn't happened yet: No developer has been able and willing to invest the additional time required to set it up and to commit to maintaining it. Also, it doesn't help that no bugtracking software exists that OpenBSD developers are enthusiastic about. But that is a very minor problem. If a developer would decide to set up a bugtracker, i have no doubt that they would find usable software for it. So please do not discuss which is the best bugtracker software, that would be a completely pointless discussion. Besides, maybe Kristaps will write it on some cold, rainy July day in La Valetta. *eg* Yours, Ingo |
In reply to this post by Philipp Buehler
2017-06-19 19:01 GMT+02:00 Philipp Buehler <
[hidden email]>: > Am 19.06.2017 18:51 schrieb Harald Dunkel: > >> some reliable response time >> > > I've to decide between popcorn and other stuff with flames. > > Entitlement is a strong feeling, it seems. -- May the most significant bit of your life be positive. |
In reply to this post by Harald Dunkel-5
why, it seems to be working fine for the guys in charge of the project.
-l On Mon, Jun 19, 2017 at 10:51 AM, Harald Dunkel <[hidden email]> wrote: > Hi folks, > > 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? > > Currently I have the impression that you have to be very lucky > to be recognized on [hidden email]. This is highly frustrating > and discouraging. > > > Regards > Harri > > |
In reply to this post by Ingo Schwarze
On Mon, Jun 19, 2017 at 07:26:14PM +0200, Ingo Schwarze wrote:
> Hi, > > Harald Dunkel wrote on Mon, Jun 19, 2017 at 06:51:24PM +0200: > > > would it be possible to establish a real bug tracking system > > for OpenBSD? > > There is exactly one reason it hasn't happened yet: > > No developer has been able and willing to invest the additional > time required to set it up and to commit to maintaining it. Yes. Exactly that. I have been willing for a while, but I can't invest more time into the project than I currently do. Maybe once I'm retired and don't need a $dayjob ;-) -- Antoine |
In reply to this post by Ingo Schwarze
On Jun 19 19:26:14, [hidden email] wrote:
> Besides, maybe Kristaps will write it on some cold > rainy July day in La Valetta. *eg* It has dawned on me: sponsor cold, rainy days for obsd developers, with nothing but a laptop. A cottage on the Czech/German border is available in November. |
In reply to this post by Ingo Schwarze
On 2017-06-19, Ingo Schwarze <[hidden email]> wrote:
> Hi, > > Harald Dunkel wrote on Mon, Jun 19, 2017 at 06:51:24PM +0200: > >> would it be possible to establish a real bug tracking system >> for OpenBSD? > > There is exactly one reason it hasn't happened yet: > > No developer has been able and willing to invest the additional > time required to set it up and to commit to maintaining it. It is the second part, "commit to maintaining it", which is the real problem. This isn't just about sysadmin and software updates, but about triage, removing dead/bogus reports etc. When GNATS was removed, there were a huge number of open tickets. Some valid, but many many were invalid. |
In reply to this post by Harald Dunkel-5
On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote:
> Hi folks, > > 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 -- Carlin |
Thanks for the link. That was a fun read. Another reason I love OBSD. Take things seriously but have fun doing it.
Sent from BlueMail On Jun 20, 2017, 6:21 AM, at 6:21 AM, Carlin Bingham <[hidden email]> wrote: >On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote: >> Hi folks, >> >> 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 > >-- >Carlin |
In reply to this post by Ingo Schwarze
Good morning,
In regards to this: >> would it be possible to establish a real bug tracking system >> for OpenBSD? > > There is exactly one reason it hasn't happened yet: > > No developer has been able and willing to invest the additional > time required to set it up and to commit to maintaining it. What would a potential curator of a bug tracker need to do besides spin up a server, install, and maintain the chosen (or written) software? Cheers, Kai |
In reply to this post by Carlin Bingham
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 |
In reply to this post by Philipp Buehler
On Mon, Jun 19, 2017 at 07:01:13PM +0200, Philipp Buehler wrote:
> Am 19.06.2017 18:51 schrieb Harald Dunkel: > > some reliable response time > > I've to decide between popcorn and other stuff with flames. Or just point out the support list? http://www.openbsd.org/support.html I guess most people and companies on that list wouldn't mind fielding bugs with reliable response time, for a price :-) |
In reply to this post by Kai Wetlesen
Kai Wetlesen wrote:
> What would a potential curator of a bug tracker need > to do besides spin up a server, install, and maintain > the chosen (or written) software? not underestimate the effort involved. so this has come up before, and the answer remains the same. anyone can setup a bug tracker, and feed bugs into it. close the ones that get fixed, categorize the rest, etc.. do that for a few months and see how it goes. i'm not really interested in looking at an empty bug database. nor one that's filled with crap. so yeah, there's a bootstrapping problem. you don't have to announce your bug database the first day you set it up. in fact, it's better not to. but in a few months time, when somebody inevitably asks misc how do i contribute, where's the todo list, you'll have this handy list of unresolved bugs to point them at. like a lot of projects that seem really easy, you'd think somebody would just do it if it were that simple. but the idea that nobody wants to chance investing time in a deadend project suggests they kind of know the time investment isn't just a saturday afternoon. |
> Kai Wetlesen wrote:
> > What would a potential curator of a bug tracker need > > to do besides spin up a server, install, and maintain > > the chosen (or written) software? > > not underestimate the effort involved. > > so this has come up before, and the answer remains the same. anyone can setup > a bug tracker, and feed bugs into it. close the ones that get fixed, > categorize the rest, etc.. do that for a few months and see how it goes. > > i'm not really interested in looking at an empty bug database. nor one that's > filled with crap. so yeah, there's a bootstrapping problem. > > you don't have to announce your bug database the first day you set it up. in > fact, it's better not to. but in a few months time, when somebody inevitably > asks misc how do i contribute, where's the todo list, you'll have this handy > list of unresolved bugs to point them at. > > like a lot of projects that seem really easy, you'd think somebody would just > do it if it were that simple. but the idea that nobody wants to chance > investing time in a deadend project suggests they kind of know the time > investment isn't just a saturday afternoon. > Indeed, this thread is full of volunteers, isn't it? Why haven't one of you already started doing it? (not including Ted, Ingo, or Antoine, or myself) |
Free forum by Nabble | Edit this page |