bug tracking system for OpenBSD

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

bug tracking system for OpenBSD

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.
> >
>
> Theo de Raadt wrote:
> 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)
There are many decisions that would need to be made that will piss somebody
off. Decisions like what software/platform to use, where to host the thing, and
how much the tool should integrate into existing bug reporting mechanisms
(right now just fancy emailing).

To answer your tactful question Theo, I personally haven’t done anything because
I do not have your blessing nor of someone who can say “yes just effing do it". But,
if you would be willing to give me free reign it will be done.

~Kai

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Allan Streib-2
Kai Wetlesen <[hidden email]> writes:

> There are many decisions that would need to be made that will piss
> somebody off. Decisions like what software/platform to use, where to
> host the thing, and how much the tool should integrate into existing
> bug reporting mechanisms (right now just fancy emailing).

So it's a lot more work than it might first appear.

> To answer your tactful question Theo, I personally haven’t done
> anything because I do not have your blessing nor of someone who can
> say “yes just effing do it". But, if you would be willing to give me
> free reign it will be done.

You seem to be asking for endorsement of something you haven't done
yet. In my time on this list I've learned that's not how it works.

Allan

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Ted Unangst-6
In reply to this post by Kai Wetlesen
Kai Wetlesen wrote:
> > > 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.

> There are many decisions that would need to be made that will piss somebody
> off. Decisions like what software/platform to use, where to host the thing, and
> how much the tool should integrate into existing bug reporting mechanisms
> (right now just fancy emailing).
>
> To answer your tactful question Theo, I personally haven’t done anything because
> I do not have your blessing nor of someone who can say “yes just effing do it". But,
> if you would be willing to give me free reign it will be done.

Imagine if you'd followed my suggestion and spent the last six months curating
a bug database. Then today you could have sent us a link to it and everybody
would see how useful it is. Now we have to wait another six months.

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Kai Wetlesen

> On Dec 19, 2017, at 14:54, Ted Unangst <[hidden email]> wrote:
>
> Kai Wetlesen wrote:
>>>> 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.
>
>> There are many decisions that would need to be made that will piss somebody
>> off. Decisions like what software/platform to use, where to host the thing, and
>> how much the tool should integrate into existing bug reporting mechanisms
>> (right now just fancy emailing).
>>
>> To answer your tactful question Theo, I personally haven’t done anything because
>> I do not have your blessing nor of someone who can say “yes just effing do it". But,
>> if you would be willing to give me free reign it will be done.
>
> Imagine if you'd followed my suggestion and spent the last six months curating
> a bug database. Then today you could have sent us a link to it and everybody
> would see how useful it is. Now we have to wait another six months.

Put bluntly, I was busy with completing my bachelors degree which was far
more important. You would have waited six months regardless. Now that it’s
done and out of the way I’ll happily take your advice.
Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Ed Ahlsen-Girard-2
In reply to this post by Kai Wetlesen
On Mon, 18 Dec 2017 15:05:53 -0800
Kai Wetlesen <[hidden email]> wrote:

>  [...]  
>  [...]  
>  [...]  
>  [...]  
>
> There are many decisions that would need to be made that will piss
> somebody off. Decisions like what software/platform to use, where to
> host the thing, and how much the tool should integrate into existing
> bug reporting mechanisms (right now just fancy emailing).
>
> To answer your tactful question Theo, I personally haven’t done
> anything because I do not have your blessing nor of someone who can
> say “yes just effing do it". But, if you would be willing to give me
> free reign it will be done.
>
> ~Kai

Mr. Wetlesen,

I believe the feedback you've received amounts to "go ahead and try,
we'll review it when you've done something." You'll certainly have free
rein to submit what you wish, but if you're asking for authority to
create anything with a guarantee that it will be implemented, I think
you'll be refused.

--

Edward Ahlsen-Girard
Ft Walton Beach, FL

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Ted Unangst-6
In reply to this post by Kai Wetlesen
Kai Wetlesen wrote:
> Put bluntly, I was busy with completing my bachelors degree which was far
> more important. You would have waited six months regardless. Now that it’s
> done and out of the way I’ll happily take your advice.

No need to explain that other things come up. OpenBSD developers are aware
this happens. It's everybody else that seems to forget. :)

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Stuart Henderson
In reply to this post by Kai Wetlesen
On 2017-12-18, Kai Wetlesen <[hidden email]> wrote:

> There are many decisions that would need to be made that will piss
> somebody off. Decisions like what software/platform to use, where to
> host the thing, and how much the tool should integrate into existing bug
> reporting mechanisms (right now just fancy emailing).

The important part is the data itself.

Pretty much everyone who has been making suggestions about a bug
tracking system has been talking about things like choice of software,
hosting, setting it up. That's not really important. As long as the
database can be exported if necessary, the actual choice of platform
doesn't matter much.

By far the largest amount of work involved is in triage and follow-up
of tickets, things like turning "After upgrading from 6.0-stable to
6.2-stable (syspatch) existing setup started to hang" into something
meaningful, requesting more information, closing tickets when they're
fixed, etc.

So the best choice of tracking system is whatever is acceptable to
whoever is doing that work.

IMHO if anything is going to happen with this it's going to come
from someone who just gets on and does it. Maybe someone who just
throws a spreadsheet or something together to keep track of
tech@/bugs@ mails. I'd be very surprised if a useful system
comes from someone who is looking at it as a technical exercise
of setting up the system.


Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Kapetanakis Giannis
On 22/12/17 17:36, Stuart Henderson wrote:

> The important part is the data itself.
> ...
> IMHO if anything is going to happen with this it's going to come
> from someone who just gets on and does it. Maybe someone who just
> throws a spreadsheet or something together to keep track of
> tech@/bugs@ mails. I'd be very surprised if a useful system
> comes from someone who is looking at it as a technical exercise
> of setting up the system.


I agree with you that the important is the data itself and not the system chosen for the work.

Such a movement can start from zero ground without migrating data from @bugs or @tech.

But to be fair with the OP it all depends on dev's (mainly) willingness to track/respond/close tickets.
I say devs because these are the people who commit fixes of bugs and so they should monitor/update this system as well. It's extra work for them instead of developing... and I understand that.

I don't see a reason @tech should be forwarded to this ticket system.

@bugs can be eventually closed or somehow migrated to this system (new mails and not existing ones).

Personally I would like to see such a system in OB.

G

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Mike.
On 12/22/2017 11:26 AM, Kapetanakis Giannis wrote:

> On 22/12/17 17:36, Stuart Henderson wrote:
>
>> The important part is the data itself.
>> ...
>> IMHO if anything is going to happen with this it's going to come
>> from someone who just gets on and does it. Maybe someone who just
>> throws a spreadsheet or something together to keep track of
>> tech@/bugs@ mails. I'd be very surprised if a useful system
>> comes from someone who is looking at it as a technical exercise
>> of setting up the system.
>
>
> I agree with you that the important is the data itself and not the system chosen for the work.
>
> Such a movement can start from zero ground without migrating data from @bugs or @tech.
>
> But to be fair with the OP it all depends on dev's (mainly) willingness to track/respond/close tickets.
> I say devs because these are the people who commit fixes of bugs and so they should monitor/update this system as well. It's extra work for them instead of developing... and I understand that.
>
> I don't see a reason @tech should be forwarded to this ticket system.
>
> @bugs can be eventually closed or somehow migrated to this system (new mails and not existing ones).
>
> Personally I would like to see such a system in OB.




> so they should monitor/update this system as well

Therein is the issue, in my eyes.

"should" instead of "want to."

The system needs to provide enough of a benefit to those who use it that
they want to use.

No amount of shiny objects is going to change that.

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Stuart Henderson
In reply to this post by Kapetanakis Giannis
On 2017-12-22, Kapetanakis Giannis <[hidden email]> wrote:
> But to be fair with the OP it all depends on dev's (mainly)
> willingness to track/respond/close tickets.
>
> I say devs because these are the people who commit fixes of bugs and
> so they should monitor/update this system as well. It's extra work for
> them instead of developing... and I understand that.

I'm sure that often devs will do this, but sometimes not (maybe they'll
forget, maybe they'll fix something without noticing that it relates to
a ticket, etc). It needs someone to take responsibility for maintaining
the database, if it's left *only* up to the developer fixing a problem
you're just going to end up with the gnats database and hundreds (or was
it thousands) of tickets in limbo again.

> I don't see a reason @tech should be forwarded to this ticket system.

Forwarded? No way! Same for bugs@ as tech@. It needs manual work to
triage, identify what is a bug, follow up with the reporter to make
sure the report is accurate and has enough information to be useful.
Same whatever the entry point is. If reporters can add bugs to it
directly, they need to go into a triage queue and *not* appear in the
main system until that's done.

The idea of a bug tracking system is to spread the work and help
people remember things. It should *reduce* work done by devs because
they no longer have to drag even the most basic information out
of a reporter and figure out whether it's a bug or user error
or a support request in disguise.

If it means *extra* work for devs, it's not going to work.


Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Kapetanakis Giannis
On 23/12/17 12:24, Stuart Henderson wrote:

> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to
> triage, identify what is a bug, follow up with the reporter to make
> sure the report is accurate and has enough information to be useful.
> Same whatever the entry point is. If reporters can add bugs to it
> directly, they need to go into a triage queue and *not* appear in the
> main system until that's done.
>
> The idea of a bug tracking system is to spread the work and help
> people remember things. It should *reduce* work done by devs because
> they no longer have to drag even the most basic information out
> of a reporter and figure out whether it's a bug or user error
> or a support request in disguise.
>
> If it means *extra* work for devs, it's not going to work.
>
>

I still don't agree with you about maintaining both @tech/@bugs in
correlation with a web interface (bugtracking).
Not a gain, just extra trouble.

What happens in other places is that if a mail comes that looks like a
possible ticket (not resolvable by mail), someone replies and says
"please open bug report in https://..."
so we can track it.

However you 're right with the last paragraph above and it's something I
haven't thought before.
More people might get involved and eventually this might get some work
out of the devs.

G

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Marko Cupać
While not exactly bug tracker, more like general-purpose issue tracker,
I have successfully implemented rt44 in a company I work for:

[https://docs.bestpractical.com/rt/4.4.2/README.html]

The reason why I succeeded with rt44, and failed with other, shinier
trackers with more bells and whistles, is its integration with email.
All of my users want single email address where they can report issues.
Some of my colleagues in IT want to continue using email-only
correspondence while dealing with users' issues, while others prefer to
use additional features in rt44's web interface. All of them can have
their way with rt. No one was forced to something new, something
different. Email-only is still there, with the addition of web
interface for those who want/like it.

If OpenBSD people are interested, I can provide complete rt44-based
solution directly from my servers, or I can help building and
integrating it on some other hardware.

Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Stuart Henderson
In reply to this post by Kapetanakis Giannis
On 2017-12-23, Kapetanakis Giannis <[hidden email]> wrote:

> On 23/12/17 12:24, Stuart Henderson wrote:
>> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to
>> triage, identify what is a bug, follow up with the reporter to make
>> sure the report is accurate and has enough information to be useful.
>> Same whatever the entry point is. If reporters can add bugs to it
>> directly, they need to go into a triage queue and *not* appear in the
>> main system until that's done.
>>
>> The idea of a bug tracking system is to spread the work and help
>> people remember things. It should *reduce* work done by devs because
>> they no longer have to drag even the most basic information out
>> of a reporter and figure out whether it's a bug or user error
>> or a support request in disguise.
>>
>> If it means *extra* work for devs, it's not going to work.
>>
>>
>
> I still don't agree with you about maintaining both @tech/@bugs in
> correlation with a web interface (bugtracking).
> Not a gain, just extra trouble.

Probably not long term, but looking at existing unfixed bug reports on
lists would be a good way to seed the database. And information spread
across multiple mails can be synthesized into a coherent report,
hopefully going some way to showing others what a proper bug
submission should actually look like.

> What happens in other places is that if a mail comes that looks like a
> possible ticket (not resolvable by mail), someone replies and says
> "please open bug report in https://..."
> so we can track it.
> However you 're right with the last paragraph above and it's something I
> haven't thought before.
> More people might get involved and eventually this might get some work
> out of the devs.


Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Kai Wetlesen
Agreed, partially, with both of you. It may be possible to automatically filter
some of the chaff (user errors and support requests in disguise)
in one large batch so to pressed the DB but forwarding mailing list touches
to the bug tracker would make things ugly fast.

What would be involved to pull the current state of bugs@ and tech@?

> On Dec 25, 2017, at 12:21, Stuart Henderson <[hidden email]> wrote:
>
>> On 2017-12-23, Kapetanakis Giannis <[hidden email]> wrote:
>>> On 23/12/17 12:24, Stuart Henderson wrote:
>>> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to
>>> triage, identify what is a bug, follow up with the reporter to make
>>> sure the report is accurate and has enough information to be useful.
>>> Same whatever the entry point is. If reporters can add bugs to it
>>> directly, they need to go into a triage queue and *not* appear in the
>>> main system until that's done.
>>>
>>> The idea of a bug tracking system is to spread the work and help
>>> people remember things. It should *reduce* work done by devs because
>>> they no longer have to drag even the most basic information out
>>> of a reporter and figure out whether it's a bug or user error
>>> or a support request in disguise.
>>>
>>> If it means *extra* work for devs, it's not going to work.
>>>
>>>
>>
>> I still don't agree with you about maintaining both @tech/@bugs in
>> correlation with a web interface (bugtracking).
>> Not a gain, just extra trouble.
>
> Probably not long term, but looking at existing unfixed bug reports on
> lists would be a good way to seed the database. And information spread
> across multiple mails can be synthesized into a coherent report,
> hopefully going some way to showing others what a proper bug
> submission should actually look like.
>
>> What happens in other places is that if a mail comes that looks like a
>> possible ticket (not resolvable by mail), someone replies and says
>> "please open bug report in https://..."
>> so we can track it.
>> However you 're right with the last paragraph above and it's something I
>> haven't thought before.
>> More people might get involved and eventually this might get some work
>> out of the devs.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

bytevolcano
If I were to set such a thing up, I wouldn't even bother pulling stuff
from tech@ and bugs@ at all. Too much work, no real benefit. I would
simply have the bug tracker to all new bugs, and maybe keep the bugs@
list open concurrently with the tracker for a period to allow older bugs
to be resolved.

Before all that, I would ask if OpenBSD really needs a bug tracker.
The project seems to do well even without one, and maybe the devs are
satisfied with bugs@ and tech@ already. What issues/problems in
workflow will a bug tracker resolve that cannot be covered by bugs@ and
tech@ lists?

On Mon, 25 Dec 2017 14:46:25 -0800
Kai Wetlesen <[hidden email]> wrote:

> Agreed, partially, with both of you. It may be possible to automatically filter
> some of the chaff (user errors and support requests in disguise)
> in one large batch so to pressed the DB but forwarding mailing list touches
> to the bug tracker would make things ugly fast.
>
> What would be involved to pull the current state of bugs@ and tech@?

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Stuart Henderson
In reply to this post by Kai Wetlesen
On 2017-12-25, Kai Wetlesen <[hidden email]> wrote:
> Agreed, partially, with both of you. It may be possible to automatically filter
> some of the chaff (user errors and support requests in disguise)
> in one large batch so to pressed the DB but forwarding mailing list touches
> to the bug tracker would make things ugly fast.
>
> What would be involved to pull the current state of bugs@ and tech@?

Somebody reading the posts, asking the right questions where information
is missing, and writing up the problems.

This is not something that can be automated.


Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

temp+101
In reply to this post by Stuart Henderson
On Sat, Dec 23, 2017 at 10:24:25AM +0000, Stuart Henderson wrote:
> The idea of a bug tracking system is to spread the work and help
> people remember things. It should *reduce* work done by devs because
> they no longer have to drag even the most basic information out
> of a reporter and figure out whether it's a bug or user error
> or a support request in disguise.
>
> If it means *extra* work for devs, it's not going to work.
>

I think that a simple directory in CVS repository could do that.  Also
it can be updated simply using `cvs commit'.  The directory sould have
plain text files for each unsolved issue.

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

nawi
In reply to this post by bytevolcano
From the original question of the OP

> ... and (very important) some reliable response time and ...

> Currently I have the impression that you have to be very lucky
to be recognized on [hidden email]. This is highly frustrating
and discouraging.

OpenBSD is developed entirely by volunteers. IMHO And, developers do
that in there spare time, they also have a family and a social life.
Even there is a bug tracker, if the OP can't be patient the answer
will always be like, shutup and hack yourself or, hire someone from
the list of commercial service.

Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Stuart Henderson
In reply to this post by bytevolcano
On 2017-12-26, <[hidden email]> <[hidden email]> wrote:
> If I were to set such a thing up, I wouldn't even bother pulling stuff
> from tech@ and bugs@ at all. Too much work, no real benefit.

"too much work". I think you misunderstand bug trackers. They aren't some
magic thing that automatically turns a submission into a usable bug report.
Whether reports are coming from list posts or ticket submissions, the
triage and information gathering still needs to be done.

> The project seems to do well even without one, and maybe the devs are
> satisfied with bugs@ and tech@ already. What issues/problems in
> workflow will a bug tracker resolve that cannot be covered by bugs@ and
> tech@ lists?

bugs/tech@ are better than the sort of tracker you'll get from someone
who thinks it's enough to just set it up, let people post bugs to it,
and lets devs deal with the rest. But they definitely have problems.

- Forgotten unfixed bugs.

- Forgotten *fixed* bugs (i.e. where the fix hasn't been committed).

- Crappy bug reports where developers have to drag the information out
of the reporter and it gets fragmented across a dozen posts, some
on list, some in private mail.

In short: if someone wants to do the work to fix this, that's great
and I'm trying to make sure anyone thinking about this has an idea of
the work involved. It would be a useful way someone with good general
knowledge of the OS but maybe not so much in the way of coding skills
could help. But at the same I'm trying to make sure people know that
simply setting up ticketing software then walking away is not going
to be helpful.


Reply | Threaded
Open this post in threaded view
|

Re: bug tracking system for OpenBSD

Sergey Bronnikov-3
In reply to this post by Ted Unangst-6
On 17:54 Tue 19 Dec , Ted Unangst wrote:

> Kai Wetlesen wrote:
> > > > 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.
>
> > There are many decisions that would need to be made that will piss somebody
> > off. Decisions like what software/platform to use, where to host the thing, and
> > how much the tool should integrate into existing bug reporting mechanisms
> > (right now just fancy emailing).
> >
> > To answer your tactful question Theo, I personally haven’t done anything because
> > I do not have your blessing nor of someone who can say “yes just effing do it". But,
> > if you would be willing to give me free reign it will be done.
>
> Imagine if you'd followed my suggestion and spent the last six months curating
> a bug database. Then today you could have sent us a link to it and everybody
> would see how useful it is. Now we have to wait another six months.

I have made a first step forward in direction to OpenBSD bugtracker
and imported bugs@ archive to a Fossil SCM -
https://bronevichok.ru/cgi-bin/b.cgi/rptview?rn=1
Let's discuss a next step.

123