kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

> 
> * 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.  Opinion and wont fix
should be addressed by the lead developers.  To me, opinion is a synonym
for wishlist.

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

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

> 
> Bye,
> imp
> 

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.

Best Regards,

Wayne