kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 2/21/2014 8:34 PM, Martin Janitschke wrote:
> On 22.02.2014 01:58, Wayne Stambaugh wrote:
>> On 2/21/2014 3:11 PM, Martin Janitschke wrote:
>>> Heyho, currently I'm looking through the tickets in the bug
>>> tracker and trying clean up a bit (verifying the bugs, checking
>>> if they still exists and such).
>>>
>>> There are some questions: * Bug importance: didn't touched those
>>> due to the descriptions on the levels, but I would really like to
>>> mark some bugs (like the DRC missing errors, example:
>>> https://bugs.launchpad.net/kicad/+bug/1201090 ) as "High" or
>>> "Critical". Can we have some guidelines for this? (Or is there an
>>> existing one?). IMHO such bugs deserve more attention compared
>>> to misfits in the UI since they allow faulty output at the end.
> 
>> Please save critical for things like build errors and crash bugs. 
>> Everything else should have a lower priority.  This is where it
>> gets tricky.  One person's high importance is low to the next
>> person.  To me, the DRC issue is not critical because I never
>> depend on them.  I've been bit too many times to trust them at all.
>> I would say the DRC bugs should be moderate and I would reserve
>> high importance for items like incorrect gerber or drill file
>> generation.
> Ok. Maybe a warning in the DRC window about current known limitations
> / shortcomings would be nice - this way the user is at least informed
> about that (even if it might be a bit embarrassing - but it can also
> be encouraging to send some patches).
> 
>>> * Cases of "Works for me" / "Works in current version" (with an 
>>> incomplete bug report, missing the version it was reported for) -
>>> are those "Invalid - Not a bug. May be a support request or
>>> spam." or "Wont fix - Doesn't fit with the project plans, sorry."
>>> (they might fit "Fix committed" but that's hard to determine in
>>> such cases). Those descriptions are far away from what I'm used
>>> to... (I'm missing "Wont fix - works for me" or " Invalid - can't
>>> reproduce").
> 
>> Most of these should be self explanatory.  If you can't reproduce
>> it in the latest product branch than it probably has been
>> addressed.  You may want to ping the submitter to see if they can
>> still reproduce it before tagging it as fix committed.  If no KiCad
>> version information is included in the report, tag it as
>> incomplete.
> Same for missing files to reproduce the bug. That's one of the states
> that are fine ;).
> Pinging will happen by commenting on the bug (since the reporter
> should get the bug mail)?
> 
>> Opinion and wont fix should be addressed by the lead developers.
>> To me, opinion is a synonym for wishlist.
> I already set one bug to "Opinion" before I saw your mail - but there
> was a lengthy discussion from said group.
> 
>>> * Due to the current "rolling release / something close to that",
>>> bugs that are fixed, are marked as such and not "fix released" -
>>> correct? Will someone mark them after a release / bzr tag will
>>> set those to "fix released"?
> 
>> Fixed released should be used only when a new stable version (which
>> is probably going to go away so I don't know if it's worth the time
>> to update them) is released with the bug fix.  Otherwise, fix
>> committed should be used when it has been fixed in the product
>> branch.  The problem is no one goes back and changes them from
>> committed to released when there is a new stable release so.
>> Unless there is a way to tell Launchpad to do it automatically by
>> branch, revision, or tag, I'm not sure if there is a good solution
>> for this.  Doing it by hand would be a lot of work.
> Maybe this will happen if the report was assigned to an milestone?
> Sadly I don't know much about the workflow from launchpad and what
> will happen if a milestone is completed.

Technically bug fix commits should be committed with the
--fixes=lp:xxxxx option so that a bzr revision is associated with the
launchpad bug but it doesn't always happen.

> 
>>> * Reports regarding symbols and footprints - should they be
>>> redirected to https://github.com/KiCad/kicad-library and if so,
>>> what state should be set after this?
> 
>> Patches and bug reports for component symbol and footprint
>> libraries should be redirected since this is the new home for
>> them.
> Redirect and close ("Invalid")?
> Hope those reports will be addressed there.
> 
>> Thank you for cleaning up the bug reporting system.  This is one of
>> the those thankless jobs that really needs to be done.  I for
>> appreciate the help.
> Np, someone has to do it. Hope the rest will follow ones it'll be more
> usable again.
> 
> Bye,
> imp
> 

I noticed there are a bunch of MSVC compiler bug reports.  Please add a
comment that the MSVC compiler is no longer supported and tag the bug as
wont fix to all bugs reports related to the MSVC compiler.  This
decision was made by the lead developers well over a year ago and it
will not be reopened any time soon.

Thanks,

Wayne