kicad-developers team mailing list archive

[Martin Janitschke <imp@xxxxxxxxxxxxxxx>]

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