Bug-Tracker

So, ich habe den Bug-Tracker auf BerliOS wieder aktiviert.
Dort kann man Bug-Kategorien und Bug-Gruppen festlegen.
Als Kategorien habe ich bisher angelegt:
* Solver
* High-Res on mobile
* Map
* GC-Spider

Ich wollte die Fehler, mit denen wir zu rechnen haben (bzw. die in der Vergangenheit besonders stark diskutiert wurden), in möglichst ähnlich große Kategorien zusammenfassen.
Da man aber Kategorien später nicht mehr löschen kann, sollten wir hier uns irgendwas sinnvolles überlegen.

Bei den Gruppen schlage ich vor:
* bug unconfirmed
* bug confirmed
* bug reproduceable
* bug reason found in code
* fixed, ready to test
* fixed, tested
* FR from user
* FR refused
* FR implemented

Was meint Ihr?

Die Frage ist auch, wie und ob sollen wir Eve und Ewe trennen?
Mir scheint, man kann leider nicht einfach zusätzlich noch Kategorien Eve und Ewe anlegen und sie zusätzlich dem Bug zuweisen.


Gruß,
Pfeffer.

Gibts da nicht irgendwo nen Demo-Mode, wo man mal gucken kann, wie der Bugtracker so tickt?

Gruß,
E.

EWE würde ich dort nicht mehr aufnehmen. Das bindet nur unnötig Kapazitäten.

Brauchen wir noch eine Kategorie, die alles aufnimmt, was bisher keiner anderen Kategorie zugeordnet werden kann?

Zu den "Gruppen" gehört meiner Ansicht nach noch:
* bug not reproducable
* bug won't fix

Denn nicht alles, was als Bug gemeldet werden wird, wird auch einen Fix bekommen.

Viellleicht brauchen wir auch noch einen Zustand für Bugs, die geschlossen werden, weil sie ein Duplikat von einem vorhandenen sind.

Ich habe gerade mal kurz rein geschaut. Gehört die Liste, die Du als "Gruppen" aufgeführt hast nicht eher in das "Status"-Feld? Oder kann man diese Liste nicht erweitern?

Edit: OK, stimmt wohl so. Auch wenn ich es irgendwie anders erwartet hätte.

Hallo,

wie schaut es mit
"Accepted bug" aus?

Meint:
Ist zwar ein Fehler, wird aber aus welchen Gründen auch immer nicht behoben.
(zu aufwändig, überhaupt nicht möglich etc.)

klausundelke schrieb:

Ist zwar ein Fehler, wird aber aus welchen Gründen auch immer nicht behoben.
(zu aufwändig, überhaupt nicht möglich etc.)

Zum Vergrößern anklicken....

Das meinte ich mit dem "won't fix". So kenne ich die Bezeichnung von Bugzilla.

ja, wobei ich draus machen würde:
"won't fix in foreseeable time"
hmmm - ich weiß nicht, irgendwie find ich das schwierig. Wir hatten in der Vergangenheit mehrere Bugs, wo ich gesagt hätte: "won't fix in foreseeable time", aber irgendjemand hat es dann doch gemacht.
Deswegen würde ich die eigentlich einfach auf "bug cause identified" stehen lassen. Das Bug-Tracking-System ist ja nicht nur als Info für die User, sondern auch als Motivation für die Entwickler von Bedeutung. Ich vermute irgendwie, dass die Motivation, sich um einen auf "won't fix" Bug zu kümmern kleiner ist als um einen, "should be fixed for next minor release". Aber vielleicht wird ja auch gerade durch "won't fix" die Motivation gesteigert, weil dem Löser eines "won't fix"-Bug besondere Ehre zu teil wird? hm.

"accepted bug" hätte ich übrigens genau andersherum interpretiert: Wir haben den Bug als zu behebenden akzeptiert.

Sollten wir noch folgende Gruppen hinzufügen?
* should be fixed for next minor release
* should be fixed for next major release
* release blocking bug

Oder zumindest eine davon?

Gruß,
Pfeffer.

pfeffer schrieb:

ja, wobei ich draus machen würde:
"won't fix in foreseeable time"
hmmm - ich weiß nicht, irgendwie find ich das schwierig. Wir hatten in der Vergangenheit mehrere Bugs, wo ich gesagt hätte: "won't fix in foreseeable time", aber irgendjemand hat es dann doch gemacht.
Deswegen würde ich die eigentlich einfach auf "bug cause identified" stehen lassen. Das Bug-Tracking-System ist ja nicht nur als Info für die User, sondern auch als Motivation für die Entwickler von Bedeutung. Ich vermute irgendwie, dass die Motivation, sich um einen auf "won't fix" Bug zu kümmern kleiner ist als um einen, "should be fixed for next minor release". Aber vielleicht wird ja auch gerade durch "won't fix" die Motivation gesteigert, weil dem Löser eines "won't fix"-Bug besondere Ehre zu teil wird? hm.

Zum Vergrößern anklicken....

Ich würde eben gerne Bugs kennzeichnen, bei denen sich ein Entwickler schon mal Gedanken gemacht hat und festgestellt hat, dass das erstmal nicht lösbar ist. Weil es z.B. mit der Momentanen Struktur oder Philosophie kollidiert. Die Begründung schreibt man dann ja auch dazu. Wenn sich dann jemand berufen fühlt, kann man das ja trotzdem angehen. Aber er ist erstmal "vom Tisch". Das dient auch der Übersichtlichkeit. Bei einem "won't fix in foreseeable time" kommt dann die Diskussion alle paar Wochen wieder hoch. Bei einem harten "won't fix" ist das erstmal eine klare Entscheidung der Entwickler.

Aber ich sehe gerade, dass wir das gar nicht als Gruppe brauchen. Das gibt es ja schon bei der Auswahl für die Resolution.

pfeffer schrieb:

Sollten wir noch folgende Gruppen hinzufügen?
* should be fixed for next minor release
* should be fixed for next major release
* release blocking bug

Oder zumindest eine davon?

Zum Vergrößern anklicken....

Das würde ich eher über die Priorität abbilden. 9 heißt dann z.B. Blocker.

So, habe folgende Gruppen eingerichtet:

914 Feature Request implemented
913 Feature Request
912 Fixed, tested
710 Fixed, ready to test
911 Bug reason found in code
910 Bug reproduceable
909 Bug confirmed
908 Bug unconfirmed

und folgende Kategorien:

1865 Import/Export (GC-Spider, Garmin-Export usw.)
1461 Solver
1621 High-Res on mobile
1719 Map

Bitte macht noch weitere Vorschläge für die Kategorien.

Dann wäre ich dafür, wir geben den Prioritäten einen Sinn:
1 nice to have, sometimes
2
3
4
5
6
7
8 must be fixed before next major release
9 must be fixed before next minor release

bitte weiter ausfüllen!

BTW: Hat jeder entwickler die svn-Mailingliste aboniert? - Dorthin werden änderungen und neue Bugs auch automatisch gemeldet.

Gruß,
Pfeffer.

pfeffer schrieb:

und folgende Kategorien:

1865 Import/Export (GC-Spider, Garmin-Export usw.)
1461 Solver
1621 High-Res on mobile
1719 Map

Bitte macht noch weitere Vorschläge für die Kategorien.

Zum Vergrößern anklicken....

Auf Jeden Fall noch eine Kategorie für den Rest. Auch wenn sie generell nicht so toll ist, ist es doch besser, wie wenn solche Bugs dann irgendwo falsch einsortiert werden.

pfeffer schrieb:

BTW: Hat jeder entwickler die svn-Mailingliste aboniert? - Dorthin werden änderungen und neue Bugs auch automatisch gemeldet.

Zum Vergrößern anklicken....

Ist das die gleiche, über die man die Commits bekommt?

MiK schrieb:

pfeffer schrieb:

und folgende Kategorien:

1865 Import/Export (GC-Spider, Garmin-Export usw.)
1461 Solver
1621 High-Res on mobile
1719 Map

Bitte macht noch weitere Vorschläge für die Kategorien.

Zum Vergrößern anklicken....

Auf Jeden Fall noch eine Kategorie für den Rest. Auch wenn sie generell nicht so toll ist, ist es doch besser, wie wenn solche Bugs dann irgendwo falsch einsortiert werden.

Zum Vergrößern anklicken....

ich glaube, es gibt schon "none". Reicht das nicht?

MiK schrieb:

pfeffer schrieb:

BTW: Hat jeder entwickler die svn-Mailingliste aboniert? - Dorthin werden änderungen und neue Bugs auch automatisch gemeldet.

Zum Vergrößern anklicken....

Ist das die gleiche, über die man die Commits bekommt?

Zum Vergrößern anklicken....

ja.

pfeffer schrieb:

ich glaube, es gibt schon "none". Reicht das nicht?

Zum Vergrößern anklicken....

Ich würde auch lieber eine Kategorie "Cachewolf allgemein" oder so bevorzugen.

Gruß,
E.

"allgemein" finde ich nicht so gut, weil man dann da alles reinschmeißen kann. Die Bezeichnung sollte klar machen, dass da nur alles rein soll, was nicht in die anderen Kategorien passt. Von mir aus kann das auch "none" sein.

ich hab die Kategorie "Other" gennant.

Gruß,
Pfeffer.