kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/12/2015 6:41 PM, Brian Sidebotham wrote:
> On 12 March 2015 at 20:53, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>>
>> On 3/12/2015 2:10 PM, Nick Østergaard wrote:
>>> 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.
> 
> lp:kicad is the branch. Launchpad words things a bit weird in my
> opinion. The fact is that you *can* target any of your series per bug.
> This would not necessarily be the job the bug reporter, but instead
> would be the job of a triager. Using the bug tracker effectively is
> not just having a mass on untargetted bugs. So for each bug you get a
> "target to series" link.
> 
> From the "target to series" you can select any of the series to place
> this bug against. For the bug you linked to, just select product. If
> you select both product and stable you get two sets of status for the
> bug.
> 
> For KiCad, fix committed makes no sense for the product series, so
> once a fix is committed you will probably go straight to fix released.
> In Stable at the same time, assuming the fix is immediately
> back-ported you would select Fix committed, then when you do a release
> on that series, Launchpad marks all bugs set as Fix committed on the
> stable series to Fix Released automatically. Of course, we currently
> don't want to backport bugfixes to the stable branch and do bugfix
> releases, but when someone's wanting to see if the bug is filed they
> will (should?) search for bugs against the stable series and expect to
> find a fix committed report.

This makes much more sense to me than what we are currently doing.  I
just looked at the first 10 bug reports and none of them are linked to a
series or milestone (not sure what the difference is since I'm too lazy
to look it up) that I can see.  I agree that bugs fixed that are only
relevant to product branch should have a fix released status.  If a bug
report effects the old stable branch then it should be tagged fix
committed and become fix released after the next stable release unless
someone takes the time to apply it to the stable branch in which case it
should be tagged as fix released.

> 
> All this takes careful resource though. To use the bug tracker
> properly takes a lot of management, but if there are volunteers and
> the system can be explained you'll have a much better view of what
> bugs are currently against the product series. At the moment, there's
> only 1 bug targeted at the product series! So it will take a large
> triage effort to make sense of what's already there.
> 
> I created a quick dual-series targetted bug on KiCad-Winbuilder so you
> can see what it looks like:
> https://bugs.launchpad.net/kicad-winbuilder/+bug/1398881
> 
> Resource, Resource, Resource ( as I keep telling my bosses! )

That's the fine line I have to walk as project leader.  If resources
were unlimited, it would not be an issue.  The reality is that I have to
do what makes the most sense given the resources we have.

> 
> Best Regards,
> 
> Brian.
>