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 enlight
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 b
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.
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.
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 architect
> 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.
Wo
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 c
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
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.
> 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
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 di
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. Lat
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
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
Way to go guys, you've completely misunderstood the problem
and therefore have no solution.
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:
>
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 fi
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 fi
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 messag
Just use github, and be happy.
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 webs
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
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
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 t
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
>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. IM
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.
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 ou
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 mak
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
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 usefu
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, i
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 ca
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
>
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 sp
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@/bug
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 e
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 integrat
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 ar
> 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
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
> > > lis
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 i
> > 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.
> 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 set
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
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 peopl
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,
>>
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 requir
>> 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
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
On 2017-06-19, 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:
>
>
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.
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
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 wrote:
> Hi folks,
>
> would it be possible to establish a real bug tracking system for
> OpenBSD? Something with bug owner, severity, attachments, assignee,
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 m
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 i
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
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
58 matches
Mail list logo
