-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. >> * 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTB/6/AAoJEMrhIQwWBCkUb1sP/3QcQZRjy8JiX7LMFAp19fPg opjHTTpBWSiungJBrP6OGjFYKzAsLorv3awEdZsHrhRgGXweJoPswBNPovctJzSy KfAMXrJUk+3SKgZ/xD5dlNpVptnN4rwDiMnOnOWfBO7AGCqV7gjekZ1vCYU1pVw9 AVQuWQCPw9l8YPHWESRRPk8LJXsu0DZzk2IvUo7k/ZqVda1Zn0oCxKacciKQCRcp snlmw8FrDWVXKoi1CxL07JJvdupOx6iUsOCE4M9EzaDv9462iCrq9k8dbUt9xfbJ 7IovjKVmGGAthYUz6bX/nacok3yS0VlVZLyzAbWW0RlScsIbEbT8plSYcZF9tWMw 5ekLyLqS1wlJSHiwMNUB0aLKvuEe3W1Q+LYcibVVyrWVAwqLLcJzRnhtDnKKZ1ks 2qDm4tNp32Fk2E9rcz85Aax1CudtA5j5u/ZpHgAaeoi9r5gHIPVgPH4WlkrEh5tg 3PHRC4zDZUSW4y3naTcR2fEVpHPRWQ+pEq6n30CAVPwNy3ZGilV9o971au3ctA2N loAO+iOGwzJ3dCt8xyO6ijrFe0lG6S347NKEAqVLy4me7Vm2we3MpdxsL2nrDyi7 JcLbCvHLaDYrPrF3oKIj5aodjSqXr1I1c1tGEqQw/ciOd2ZjV+lquF2vc+nuJ2Tg quI2CZTAU5zh0pn/q9mb =Itpe -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
