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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
