What's Acceptable Bug Closure Time

Carlwill · 2010-08-21 23:38:55

I noticed I filed a bug for an issue I have only with Arch Linux. I opened a bug in regards to when I start my Arch Linux system, it 'FAILS' to start the mdadm / RAID service upon boot. It obviously does start up fine since my system shows the RAID 1 mirror healthy and synchronized. I opened a bug back in late last year or early this year (the Bug site doesn't log dates) and I would think something like this would have been corrected by now..

The bug = FS#18440

It is not impacting me using my Arch Linux system but it's very frustrating when you see something not start clean or listed as 'FAILED' during a boot. Just makes my system look unstable or ghetto.

Does anyone know why something like this would still be unresolved and or how to get something like this addressed?

Inxsible · 2010-08-22 00:06:12

Normally the Devs get to it in order of priority. But that's not a hard and fast rule. If something is very minor then they can do it along with some other bug that they might be fixing as well.

The fastest way to get something done, is to create and submit a patch.

Allan · 2010-08-22 00:10:24

Providing patches to fix the issue would help. This is a very low priority bug given it has no real issue apart from output so it will be addressed when the maintainer has time and no other high priority bugs...

Carlwill · 2010-08-22 00:24:34

I'm sorry but I am not familiar with a 'patch'.

Mustard · 2010-08-22 05:08:26

Carlwill wrote:

I'm sorry but I am not familiar with a 'patch'.

A patch is file containing specific small changes to made to a certain version of source code. It requires an understanding of the source code, or at least the changes that you might propose. It's can be submitted with a bug report, and assuming the patch is good, is one of the most helpful way of getting changes/improvements in the source code of a software project.

tpowa · 2010-08-24 13:33:06

Upstream changed the status code so i cannot do much there, brain0 works on a different raid startup in initscripts imho.

ewaller · 2010-08-24 15:15:50

I argue this with Management here at $DAYJOB all the time. I hate tracking time to closure metrics on bug reports. In my humble opinion, discrete reports of bugs may or may not point directly to the root cause, but collectively they can provide a wealth of forensics where each bug report provides a hint as root causes. Evaluating people and projecst based upon the quantity and age of bug reports discourages (1) the creation of bug reports causing the loss of vital clues and (2) encourage band-aid solutions rather than encourage improved design.

Just my 2 cents.

marfig · 2010-08-24 15:31:31

ewaller wrote:

Evaluating people and projecst based upon the quantity and age of bug reports discourages (1) the creation of bug reports causing the loss of vital clues and (2) encourage band-aid solutions rather than encourage improved design.

Too much of something is not a good thing either. Too little priority in the user of the software and too much on the software itself ends up producing software no one wants to use.
I understand your point (*). But I think you missed a disclaimer noting there instead should exist a balance between all things. And that evaluating a software based on bug reports and age is not only inevitable, but actually can be essential depending on what you plan to do with that software.

It's not up to us to define how the user should evaluate our software.

(*) although, saying "Evaluating people and projecst based upon the quantity and age of bug reports discourages the creation of bug reports", is giving ammunition to the ill intentioned.

Last edited by marfig (2010-08-24 15:34:44)

ewaller · 2010-08-24 15:39:38

marfig wrote:

...
Too much of something is not a good thing either. Too little priority in the user of the software and too much on the software itself ends up producing software no one wants to use.
...
although, saying "Evaluating people and projecst based upon the quantity and age of bug reports discourages the creation of bug reports", is giving ammunition to the ill intentioned.

Point taken :-)

Arch Linux

#1 2010-08-21 23:38:55

What's Acceptable Bug Closure Time

#2 2010-08-22 00:06:12

Re: What's Acceptable Bug Closure Time

#3 2010-08-22 00:10:24

Re: What's Acceptable Bug Closure Time

#4 2010-08-22 00:24:34

Re: What's Acceptable Bug Closure Time

#5 2010-08-22 05:08:26

Re: What's Acceptable Bug Closure Time

#6 2010-08-24 13:33:06

Re: What's Acceptable Bug Closure Time

#7 2010-08-24 15:15:50

Re: What's Acceptable Bug Closure Time

#8 2010-08-24 15:31:31

Re: What's Acceptable Bug Closure Time

#9 2010-08-24 15:39:38

Re: What's Acceptable Bug Closure Time

Board footer