kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/12/2015 2:10 PM, Nick Østergaard wrote:
> 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.

I don't see it that way.  Take bug

https://bugs.launchpad.net/kicad/+bug/1428245

for instance.  This bug fix has been release to the public in the
product branch and nightly builds.  This bug has no meaning to the
current stable release and only ever effected the product branch after
the differential pair router code was merged.  I defy you to show me
where in the bug report that shows which branch the bug report was filed
against and what other branches it may or may not effect.  If we
continue with the current system, it looks like we never fix any bugs
when we actually fix most bugs fairly quickly.  There has got to a less
confusing way to manage our bug tracker.

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

I hope your right, if not we will have to go back through the bug list
an tag them as released manually which is no better than what I am
proposing.

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

As long as bugs are linked to a branch or series than this makes more
sense but I don't see any bug reports that are set up this way.  Would
this be something that bug reporters would be able to understand or is
this going to require additional developer manpower?

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