kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2015-03-12 16:45 GMT+01:00 Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>:
> This sounds like a step up from what we're doing now.

Sort of and sort of not at all.

> On Thu, Mar 12, 2015 at 10:38 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
>>
>> There was a question asking how bugs are closed.
>>
>> https://answers.launchpad.net/kicad/+question/263366
>>
>> I didn't have a good answer so I dug around a bit and found some
>> information on the Launchpad blog about the meaning of bug status tags.
>>
>> http://blog.launchpad.net/general/of-bugs-and-statuses

yeah... that is just how launchpad is.

>> I also changed the status of two bugs from "Fix Committed" to "Fix
>> Released" and the "Open Bug" count was reduced by two.  Given the way we
>> have been handling bugs, it looks like none of bugs are ever fixed.
>> This is confusing for new developers and doesn't really make a lot of
>> sense.  I am proposing that we change the way we handle bugs as follows:
>>
>> * Once a bug fix has been committed to the project branch it should be
>> tagged as "Fix Committed" as we have always done.

Yes, keep this. But in addition to this, see some suggestions further down.

>> * The bug report status should be changed to "Fix Released" once bug is
>> confirmed as fixed by someone other than the person that authored the
>> bug fix.  I'm assuming bugs can be changed back to "New" if the
>> committed fix did not actually fix the bug but I haven't tried it yet.

I sort of have a strong opinion on this. It is not like I have been
comitting much to kicad, although I have sent a "micro" patch here and
there for bug fixes. But I have been using a nice chunk of my spare
time to improve KiCad by watching the bugtracker and try to keep it
tidy, to help the "real" developers get motivated to fix bugs. This by
making sure they will not meet bugs where not enough information is
needed, and if possible and time allows, I will see if I can
replicate. Again to give more datapoints for the one willing to fix
the bug. I also try to do other things to motivate newcomers, but I
will leave this out of this thread.

But now to my real comment on this: I don't think we should do this. I
might seem like a great concept at first, but rember the limited man
power, and not to forget it will not be too motivating for people in
the long run to do housekeeping on the tracker that, IMHO does not
really add any information, other than blur where the bugfix is
available. This is way more manual work, and this takes time and it
will even make it possible for some bugs not to be closed (here closed
means Fix Released) at all anyway.

>> * For legacy bug fixes, if the "Fix Committed" date is over a month, it
>> can be changed to "Fix Released" even if the fix has not been confirmed
>> as long as there are no additional complaints after the committed fix.

I think the "Fix Released" should only be on bugs that is actually
released as a "release" (also known as stable) and not a "nightly" or
"product" version. The fact that launchpad does not consider a
comitted bugfix closed is just terminology. If you search, you will
see lengthly discussions on this on the bugs for launchpad, and
probably on some mailing list somewhere.

What I think we should do, is to use the facilities that launchpad
have and mark bugs for a release version, and then IIRC when the
release is released, the bugs will be marked as fix released by the
launchpad janitor.

So by keeping fix comitted on bugs against the product repo, will mean
that users that use the either the release or nightly will have an
easy time to see where the bugfix is. For example a bug could be fixed
in the product, but then some user using the release version will note
the same bug, he might even search the bug tracker and identify the
bug that he is experincing, and he can see it is fix comitted. Then no
further action is needed for anyone, which is good and how it should
be.

Also we could start to use the "Confirmed" status some more, and point
newcomers (and other devs) to the confirmed bugs, if they want a task.
Then people like be can spend more time on the "New" bugs instead.

But in short. I think manually marking bugs as "Fix released" should
not be done.

Also a tip; people should start using the advanced search filter to
get the bug characteristics they are interrested in. If you use
firefox, you can bookmark it and give it a certain key, you can just
write in the address field. I use "kb" for the bugs that I look at the
most. Alternatively just a regular bookmark.

>> If anyone has any comments, please speak up.  Once we have a consensus
>> on this, I will make it an official project policy.

I have spoken. I hope you will seriously consider my response, even
though I wrote a lot of text. If the last part is a bit unclear or you
disagree (or even agree), please reply.