Re: bug tracking system for OpenBSD

2018-04-03 Thread Marko Cupać
On Sat, 31 Mar 2018 08:55:35 -0400
Eric Furman  wrote:

> You think I'm going to visit a .ru website?

Until I read this I thought nothing about your possible actions as I
knew nothing about you. Now I have negative opinion.

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

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



Re: bug tracking system for OpenBSD

2018-04-02 Thread Christoph R. Murauer
I offer to maintain / collect bugs which are posted at bugs@. The idea
of this collection is only, that no bugs are forgotten. No extra work
for the developers, no new interface / UI.

The idea is 1 page per month. In the next month only open, incomplete
and WIP bugs are kept. Open and incomplete bugs are only kept as long
as syspatch(8) support is given.

Looks like :
http://www.nawi.is/posts/2018-04-01-OpenBSD-bugs-status-04-2018.html

I don't ask about the how but I ask, whether this informations are
enough or, what is missing. There is no tracking at the above site so,
feedback is needed - thanks.

If this is useful (if not, no problem - it was only a offer), help is
welcome. As I am alone I can (at the moment) only start from now.

Regards,

Christoph




Re: bug tracking system for OpenBSD

2018-04-01 Thread Christoph R. Murauer
Thanks Bob, Theo, Chris for your detailed answers.

>From Ingos answer :

> ... Later on, when somebody would have time to look, such unprocessd
reports have low visibility because they are nothing but an old
posting on a mailing list, drowning in a lot of noise from invalid
and resolved reports.

Means for me, that a table of bugs / features are required. Instead of
reinventing the wheel and add a new interface, create a table (could
be a static site) including posting date, arch (release, stable,
current), subject, if it is not enough a description, bug / feature,
open / incomplete / WIP / closed. And, also a link back to bugs@.

As a new bug / feature is posted at bugs@ add them to the table as
open. If a dev answers, change it to incomplete / WIP and, if it is
solved then change it to closed.

A ideal world would provide complete bug reports so, the user has to
provide as much informations as possible. The dev could ask for more
informations if needed - if a dev didn´t ask for more details or the
user don´t provide them then nothing happened.

It is only a idea. I also have no team but maybe it is a option to
start for one person (from a given date and, let the past) where
others could join. Or, as Theo said, keep it as it is ... and expect,
that users ask again about - lets say - forgotten bugs / features.

Regards,

Christoph




Re: bug tracking system for OpenBSD

2018-04-01 Thread Consus
On 11:01 Sun 01 Apr, Stuart Henderson wrote:
> Please don't.

I wasn't going to. This guy jsut asked for the feedback so I wrote him.



Re: bug tracking system for OpenBSD

2018-04-01 Thread Chris Bennett
I think the issue of triage deserves a more clear explanation of just
how huge a task this really is.

A team with members who are well familiar with each architecture and
having access to the actual models/devices showing the problem.
Even a "fix" might break other models within the same architecture!
So, access to a ton of hardware is a must have.

Knowing who is working in the area needed and if they actually want to
work on the bug at all. Look at the hackathon reports:
"I had planned on working on issue X, but I found myself working instead
on issue Y with so and so". Why not? Who doesn't want to enjoy themself?

They need to have members who know enough OpenBSD internals to at least
be able to make reasonable guesses about where the problem is probably
at, else how can they figure out who might be able to work on it.

OK, this is starting to sound like forming a team of developers.

Dedicated enough to really keep at it.
This is starting to sound like a team getting paid money to really keep
at it! Do you really want to spend 4 hours every night after going to
work and coming home tired to do rather difficult work?

So, at the very least, a mountain of hardware, expertise and probably
money too.

I think Theo's comment about hitting 'd' on many bug reports is
realistic reality.

It's a shame, but I occasionally (always?) see 'submit a diff' more
often than I see diff's submitted.

One new talented developer is worth more than trying to create a bug
tracker.

Chris Bennett




Re: bug tracking system for OpenBSD

2018-04-01 Thread Theo de Raadt
> No such team exists.  the tool used is irrelevant

Well, we have that tool today: it is a mailing list.

Also, we have a team which triages bugs on there: the developers.

Is it perfect?  No.

Do things slip through the cracks?  Sure.  Because not enough people
triage.  Not enough developers.

Would a system which tracks the things which slip through the cracks
help?  No.  A mailing list archive makes it obvious that things
slipped through the cracks, but it also makes it obvious there is one
reason only why that is the case:  THE VOLUME IS TOO HIGH.

Organization is only one piece of the puzzle.  The data won't organize
itself.  The missing piece is "Organizers", who triage.  There are no
new GROUPS of people being offered to do this work.

One person can't do it.  Yet organizing people together to help us is
hard, that's for sure.  Impossible I'd say.

Would it be awesome to have a gigantic pile of shitty things
collecting in some web gui that none of us look at?  No.  Yet that is
what other project have.

It has to be cleaned up by someone who does traige.  Some projects
have companies associated who pay people to do it.  Other projects
let it build up, and when the quality gets to messy, it gets ignored.
OpenBSD was there before: Since it was being ignored I took the approach
that helped our developers have a better experience: I deleted the bug
tracker, and our source tree was better off for it.

Creating a portal where developers can do that is a waste of time.
They won't do the triage you expect them to.

I triage bugs by hitting 'd' in my mail reader.  That includes ones
I assume someone else will look at.  It includes ones I just fixed.
It includes ones from previous releases.  It includes ones I can't
look at now because I have other things going on.

And tough shit, that's the way it is.  I have no additional cycles to
handle yet-another interface to the bug reports people submit.  None
of the developers have additional cycles.  Creating a new interface,
which will be full of crap because *noone is offering additional
triage services*, won't help.

triage/tracking is only a small piece of the process of making OpenBSD
a good operating system.

So I believe we might as well stay with what we have.

This is a volunteer open source project.  That does not mean just
anyone can walk on in and volunteer the addition of a "new process"
and expect such an addition will work within our processes.

OpenBSD as a development process works.  This thread is full of people
who assume that what they see working in other places will work here.



Re: bug tracking system for OpenBSD

2018-04-01 Thread Bob Beck
Christoph, your conversation is distracting.

Nobody gives a damn about the tool. Everyone gives a damn about the triage.

I hate to break it to you, but you are not the first person to broach
this discusson.

The only way this would work is with a dedicated team of people to
triage each area and clean it up constantly.

No such team exists.  the tool used is irrelevant


On Sun, Apr 1, 2018 at 9:44 AM, Christoph R. Murauer  wrote:
> My question was serious. I am not the enemy but I think this thing
> will only work if the people who use it accept / like to use it and so
> on.
>
>> bug tracking software is 1% of the solution.  At least 80% of the
> work is triage, and noone on this thread is serious about doing
> that.
>
>



Re: bug tracking system for OpenBSD

2018-04-01 Thread Theo de Raadt
Do we want the 1% solution?  No.

Will we accept something which comes with a full triage team?  Yes.

Is a triage team being offered? No.

> My question was serious. I am not the enemy but I think this thing
> will only work if the people who use it accept / like to use it and so
> on.
> 
> > bug tracking software is 1% of the solution.  At least 80% of the
> work is triage, and noone on this thread is serious about doing
> that.
> 
> 



Re: bug tracking system for OpenBSD

2018-04-01 Thread Christoph R. Murauer
My question was serious. I am not the enemy but I think this thing
will only work if the people who use it accept / like to use it and so
on.

> bug tracking software is 1% of the solution.  At least 80% of the
work is triage, and noone on this thread is serious about doing
that.




Re: bug tracking system for OpenBSD

2018-04-01 Thread Theo de Raadt
> Would the devs accept / use a bug tracker ? I ask because I find start
> something without the devs is burning time (see the .ru domain, the UI
> posts ... ).

We'd be happy to accept a bug-tracker which is slavishly quality-managed
and continually purified and kept current by a team of dedicated people

Oh, but what is being talked about it is?

We're being told we can use some sort of fly-by-night web portal which
has had a full-of-junk mailing list imported into it

bug tracking software is 1% of the solution.  At least 80% of the work
is triage, and noone on this thread is serious about doing that.



Re: bug tracking system for OpenBSD

2018-04-01 Thread Christoph R. Murauer
Thanks for your fast answer.

I thought before, that the manual triage was the point.

Would the devs accept / use a bug tracker ? I ask because I find start
something without the devs is burning time (see the .ru domain, the UI
posts ... ).

If someone of the developers is interested a off list discussion could
maybe help.

Regards,

Christoph


> Hi Christoph,
>
> Christoph R. Murauer wrote on Sun, Apr 01, 2018 at 01:56:47PM +0200:
>
>> not a problem from the OpenBSD developers ?
>
> There *is* an actual problem:  Some bug reports are not processed
> immediately because at the time they are posted, nobody happens to
> find the time to investigate.  Later on, when somebody would have
> time to look, such unprocessd reports have low visibility because
> they are nothing but an old posting on a mailing list, drowning in
> a lot of noise from invalid and resolved reports.
>
> The task of a bugtracker would be
>
>  1. to collect as FEW as possible tickets -
> ideally only valid, unprocessed ones with complete information
>
>  2. to close them when resolved such that the number of open tickets
> stays low
>
> That's why manual triage and curation is the crucial point.
>
> Yours,
>   Ingo
>




Re: bug tracking system for OpenBSD

2018-04-01 Thread Ingo Schwarze
Hi Christoph,

Christoph R. Murauer wrote on Sun, Apr 01, 2018 at 01:56:47PM +0200:

> not a problem from the OpenBSD developers ?

There *is* an actual problem:  Some bug reports are not processed
immediately because at the time they are posted, nobody happens to
find the time to investigate.  Later on, when somebody would have
time to look, such unprocessd reports have low visibility because
they are nothing but an old posting on a mailing list, drowning in
a lot of noise from invalid and resolved reports.

The task of a bugtracker would be

 1. to collect as FEW as possible tickets -
ideally only valid, unprocessed ones with complete information

 2. to close them when resolved such that the number of open tickets
stays low

That's why manual triage and curation is the crucial point.

Yours,
  Ingo



Re: bug tracking system for OpenBSD

2018-04-01 Thread Christoph R. Murauer
Just curious, could it be, that the problem is only a problem of the
OPs from the threads (bug tracker, github mirror and so on) and, not a
problem from the OpenBSD developers ?

If I read the last section from https://www.openbsd.org/report.html it
looks like that for me. I did not search the list but I can't
remember, that someone asks which things in sendbug(1) or bugs (or
their workflow) does not work for the developers / maintainers (and if
there are things like that - IMHO they will fix them). Maybe people
also don't want to accept that OpenBSD is not Linux.

IIRC Stuart (or others) mentioned not the first time, that a human had
to manage a bug tracker - if one is needed.

Maybe I am total wrong but thats are my 2 cents about it.


> Way to go guys, you've completely misunderstood the problem
> and therefore have no solution.
>
>



Re: bug tracking system for OpenBSD

2018-04-01 Thread Stuart Henderson
On 2018-03-31, Sergey Bronnikov  wrote:
> Setup another bugtracker which you like, connect it to bugs@ and send a
> link to this thread.

Please don't.

My suggestion of looking at bugs@ as a seed is for a *person* to read
new reports, collect information into one place, figure out if it
really is a bug, write up tickets. Sounds like hard work? Yes, it is.
A bug tracker needs curation/triage, that is not something that can be
automated.

If you look at a successful bug tracker, you will not be able to see
most of this work without grovelling through dead tickets because
the already-fixed issues and veiled support requests will no longer
be visible.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Theo de Raadt
Way to go guys, you've completely misunderstood the problem
and therefore have no solution.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Sergey Bronnikov
On 21:17 Fri 30 Mar , Mike Burns wrote:
> On 2018-03-30 23.01.16 +0300, Sergey Bronnikov wrote:
> > 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
> 
> Ran it through curl:
> 
> - Your cert is invalid.
> - Why does every ticket go to /cgi-bin/b.cgi/honeypot ?

https://www.fossil-scm.org/xfer/help?cmd=/honeypot

The "/honeypot" page:
This page is a honeypot for spiders and bots.

> > Let's discuss a next step.
> 
> Are these triaged?



Re: bug tracking system for OpenBSD

2018-03-31 Thread Sergey Bronnikov
On 21:04 Sat 31 Mar , Consus wrote:
> On 23:01 Fri 30 Mar, Sergey Bronnikov wrote:
> > 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.
>
> The first obvious problem: you've imported every message in the mailing
> list as a separate ticket:

It is not so. Each ticket in bugtracker is a separate mail thread.  The
problem comes from mail archive on marc.info which I used as reports
archive - each mail is a separate thread. I believe it is due to broken
In-Reply-To field. Each ticket contains a link to the appropriate mail
thread and you can check it yourself with links below.

>   c541065d62 ... kernel/515: Byte-order confusion in CD-ROM drivers
https://marc.info/?l=openbsd-bugs=90222460531616=2

>   4136fcdc4e ... Re: kernel/515
https://marc.info/?l=openbsd-bugs=90222460531621=2

> or
>
>   3989e0a08b ... documentation/532: man page 'curs_terminfo' does not 
> exist
 https://marc.info/?l=openbsd-bugs=90222460531656=2

>   0486b260d2 ... Re: documentation/532
https://marc.info/?l=openbsd-bugs=90222460531658=2

> So the main advantage of the bug tracking system (ability to follow the
> history of actions) is lost.
>
> Or I got something wrong, the UI is kinda strange.

Setup another bugtracker which you like, connect it to bugs@ and send a
link to this thread.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Consus
On 21:04 Sat 31 Mar, Consus wrote:
> On 23:01 Fri 30 Mar, Sergey Bronnikov wrote:
> > 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.
> 
> The first obvious problem: you've imported every message in the mailing
> list as a separate ticket:
> 
>   c541065d62 ... kernel/515: Byte-order confusion in CD-ROM drivers 
>   4136fcdc4e ... Re: kernel/515
> 
> or
> 
>   3989e0a08b ... documentation/532: man page 'curs_terminfo' does not 
> exist
>   0486b260d2 ... Re: documentation/532
> 
> So the main advantage of the bug tracking system (ability to follow the
> history of actions) is lost.
> 
> Or I got something wrong, the UI is kinda strange.

Oh, I got it. User comments are being added properly only if replies to

subsytem/id: subject

are in form

RE: subsystem/id: subject

which is not always the case as

RE: subsystem/id

is also frequent.

Also ALL tickets are opened.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Consus
On 23:01 Fri 30 Mar, Sergey Bronnikov wrote:
> 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.

The first obvious problem: you've imported every message in the mailing
list as a separate ticket:

c541065d62 ... kernel/515: Byte-order confusion in CD-ROM drivers 
4136fcdc4e ... Re: kernel/515

or

3989e0a08b ... documentation/532: man page 'curs_terminfo' does not 
exist
0486b260d2 ... Re: documentation/532

So the main advantage of the bug tracking system (ability to follow the
history of actions) is lost.

Or I got something wrong, the UI is kinda strange.



Re: bug tracking system for OpenBSD

2018-03-31 Thread Rupert Gallagher
Just use github, and be happy.


Re: bug tracking system for OpenBSD

2018-03-31 Thread Eric Furman
On Fri, Mar 30, 2018, at 4:01 PM, Sergey Bronnikov wrote:
> 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.
> 

You think I'm going to visit a .ru website?



Re: bug tracking system for OpenBSD

2018-03-30 Thread Mike Burns
On 2018-03-30 23.01.16 +0300, Sergey Bronnikov wrote:
> 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

Ran it through curl:

- Your cert is invalid.
- Why does every ticket go to /cgi-bin/b.cgi/honeypot ?

> Let's discuss a next step.

Are these triaged?



Re: bug tracking system for OpenBSD

2018-03-30 Thread Peter Hessler
On 2018 Mar 30 (Fri) at 23:01:16 +0300 (+0300), Sergey Bronnikov wrote:
: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.
:

I believe the next step would be to delete the database.
_Please re-read the entire thread_.  Or even just the parts you quoted.

An example that shouldn't be displayed in the database:
 - Arrival-Date:   Tue Jul  7 17:50:01 MDT 1998

-- 
In Lexington, Kentucky, it's illegal to carry an ice cream cone in your
pocket.



Re: bug tracking system for OpenBSD

2018-03-30 Thread Sergey Bronnikov
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.



Re: bug tracking system for OpenBSD

2017-12-26 Thread Stuart Henderson
On 2017-12-26,   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.




Re: bug tracking system for OpenBSD

2017-12-26 Thread Christoph R. Murauer
>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 b...@openbsd.org. 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.



Re: bug tracking system for OpenBSD

2017-12-26 Thread 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  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@?



Re: bug tracking system for OpenBSD

2017-12-26 Thread Ali Farzanrad
On Sat, Dec 23, 2017 at 10:24:25AM +, 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.



Re: bug tracking system for OpenBSD

2017-12-26 Thread Stuart Henderson
On 2017-12-25, Kai Wetlesen  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.




Re: bug tracking system for OpenBSD

2017-12-25 Thread 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  wrote:
> 
>> On 2017-12-23, Kapetanakis Giannis  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.
> 
> 



Re: bug tracking system for OpenBSD

2017-12-25 Thread Stuart Henderson
On 2017-12-23, Kapetanakis Giannis  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.




Re: bug tracking system for OpenBSD

2017-12-25 Thread 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/



Re: bug tracking system for OpenBSD

2017-12-23 Thread 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



Re: bug tracking system for OpenBSD

2017-12-23 Thread Stuart Henderson
On 2017-12-22, Kapetanakis Giannis  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.




Re: bug tracking system for OpenBSD

2017-12-22 Thread 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.



Re: bug tracking system for OpenBSD

2017-12-22 Thread 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



Re: bug tracking system for OpenBSD

2017-12-22 Thread Stuart Henderson
On 2017-12-18, Kai Wetlesen  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.




Re: bug tracking system for OpenBSD

2017-12-21 Thread Ed Ahlsen-Girard
On Mon, 18 Dec 2017 15:05:53 -0800
Kai Wetlesen  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



Re: bug tracking system for OpenBSD

2017-12-20 Thread Ted Unangst
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. :)



Re: bug tracking system for OpenBSD

2017-12-19 Thread Kai Wetlesen

> On Dec 19, 2017, at 14:54, 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.

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.


Re: bug tracking system for OpenBSD

2017-12-19 Thread Ted Unangst
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.



Re: bug tracking system for OpenBSD

2017-12-19 Thread Allan Streib
Kai Wetlesen  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



bug tracking system for OpenBSD

2017-12-18 Thread 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
Description: Message signed with OpenPGP


Re: bug tracking system for OpenBSD

2017-06-20 Thread Theo de Raadt
> 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)



Re: bug tracking system for OpenBSD

2017-06-20 Thread Ted Unangst
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.



Re: bug tracking system for OpenBSD

2017-06-20 Thread Stefan Sperling
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 :-)



Re: bug tracking system for OpenBSD

2017-06-20 Thread Ingo Schwarze
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



Re: bug tracking system for OpenBSD

2017-06-20 Thread Kai Wetlesen
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 



Re: bug tracking system for OpenBSD

2017-06-20 Thread Edgar Pettijohn
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 <c...@viennan.net> 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


Re: bug tracking system for OpenBSD

2017-06-20 Thread Carlin Bingham
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



Re: bug tracking system for OpenBSD

2017-06-20 Thread Stuart Henderson
On 2017-06-19, Ingo Schwarze <schwa...@usta.de> 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.




Re: bug tracking system for OpenBSD

2017-06-19 Thread Jan Stary
On Jun 19 19:26:14, schwa...@usta.de 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.



Re: bug tracking system for OpenBSD

2017-06-19 Thread Antoine Jacoutot
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



Re: bug tracking system for OpenBSD

2017-06-19 Thread Luis Coronado
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 <ha...@afaics.de> 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 b...@openbsd.org. This is highly frustrating
> and discouraging.
>
>
> Regards
> Harri
>
>


Re: bug tracking system for OpenBSD

2017-06-19 Thread Janne Johansson
2017-06-19 19:01 GMT+02:00 Philipp Buehler <
e1c1bac6253dc54a1e89ddc046585...@posteo.net>:

> 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.


Re: bug tracking system for OpenBSD

2017-06-19 Thread Ingo Schwarze
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



Re: bug tracking system for OpenBSD

2017-06-19 Thread Philipp Buehler

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



bug tracking system for OpenBSD

2017-06-19 Thread Harald Dunkel
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 b...@openbsd.org. This is highly frustrating
and discouraging.


Regards
Harri