Genaues Bugtracking - jemand einen Vorschlag?

[martin1989]

Schönen Abend!

Ich bin auf der Suche nach einer Datenbank/Sammlung (vergleichbar mit zb Bugzilla), wo man von Open Source Java Systemen die Historie bezüglich Bugs analysieren kann.

Speziell will ich gerne irgend ein Softwareprodukt zB. in Version 2 als Source Code bekommen und dann auch noch den Source Code von Version 3.

Weiters würde ich dann gerne eine Art Bughistorie haben, also welche Bugs/Fehler von Version 2 auf 3 korrigiert wurden. Dies sollte genau angegeben sein, also am besten in welchem Package und in welcher Klasse und welche Zeile.

Hat jemand eine Idee wo ich so was finde?
Bzw, kennt ein Open Source Produkt das dies bereit stellt?



Bei meinen bisherigen Suchen scheiterte es meist daran, das die Bughistorie zu ungenau war und ich nicht genau nachvollziehen konnte was wo korrigiert bzw. geändert wurde oder das der Source Code von der alten Version nicht mehr zur Verfügung stand 🙂

Besten Dank!

 

[Thallius]

Was du willst ist doch nichts anderes als ein VCS

 

[martin1989]

Ok danke dies beschreibt es wohl am besten 🙂

Also weiß wer ein Open Source Java Projekt wo man Einblick in das Version Control System hat und dazu noch den Source Code jeder Version bekommt?

Ich glaube GitHub wäre so etwas was ich suche ... weiß jemand ob es da einen genauen bericht gibt wo wie was geändert wurde?

 

[Thallius]

GitHub ist genau das.

Und du kannst dir einfach zeigen lassen was sich von einem submit zum anderen geändert hat.

Ich würde Vorschlägen du beschäftigst dich einfach mal damit. Das erspart es das wir dir alles erklären müssen 😉

Gruß

Claus

 

[tffasse]

Und falls es privat sein soll (beispielsweise lokal oder auf eigenem Server, falls vorhanden) dann wäre imho GitLab die Alternative zu GitHub. Kann im Prinzip das selbe, nur kostet es auf GitHub ein privates Repository anzulegen. 🙂 GitLab ist dagegen kostenlos.

 

[martin1989]

Ich hab mich nun mal mit gutHub beschäftigt.

Hab eine Frage dazu, was ist der unterschied zwischen der master branche und zb dem letzten tag von Junit?

Wird in der Masterbranche quasi immer weiterentwickelt und wenn der code reif für ein release ist, wird dazu einfach ein tag gemacht?


Bezüglich JUnit bei github:

hier wurde die masterbranche erst vor kurzem upgedated (7 Tage) und der letzte tag im November 14.

Heisst das wenn ich die aktuelle version will, muss ich mir den code vom letzten tag runterladen und wenn ich den aktuellsten code will den coder aus der masterbranche?

 

[Joose]

Ein "Tag" makiert normalerweise eine bestimmten Codestand. Meist eben wenn eine bestimmte Version mit neuen Features usw. fertig gestellt wurde.
Theoretisch kannst du auch jede Stunde einen "Tag" erstellen 😉 ob das sinnvoll ist sei dahin gestellt.

 

[martin1989]

Hi,
danke für deine Antwort!

Ja das ist mir schon klar 🙂

weisst du auch was dann der unterschied zw. dem tag und der masterbranche ist?
bzgl. meinem bsp auf junit bezogen ...

danke, lg

 

[Joose]

weisst du auch was dann der unterschied zw. dem tag und der masterbranche ist?

Wie schon gesagt der Tag makiert den Codestand zu einem bestimmten Zeitpunkt. Der Branch entspricht dem Code während der ganzen Entwicklungszeit.
Ein Tag sollte im Nachhinein nicht mehr geändert werden, der Branch hingegen wird durch die Entwicklung natürlich weiter verändert.

Hoffe das ist etwas verständlicher, falls nicht musst du genauer beschreiben was bei dem Unterschied du nicht verstehst (bzw. was dir komisch vorkommt)

 

[martin1989]

Danke jetzt ists klar 🙂

Das heisst wenn ich zwei versionen vergleichen will ist es am besten ich verwende den code von 2 tags (also tags v1 und v2)?

Ich würde gerne einen Report haben was sich dann von v1 auf v2 geändert hat, wie kann ich mir sowas ausgeben lassen?

Danke, lg 😀

 

[martin1989]

Sinn von dem ganzen ist recht einfach erklärt:
Ich nehme den Fehlerhaften Code und analysiere ihn mit einem tool das die bug Wahrscheinlichkeit pro klasse angibt - und dann schaue ich eben anhand der bughistorie nach ob in diesen Klassen auch tatsächlich bugs waren 😉

 

[martin1989]

habs jetzt mal ein diff von zwei junit versionen versucht:

https://github.com/junit-team/junit/compare/r4.10...r4.11

kann ich mir das jetzt irgenwie einschränken das nur änderungen aufscheinen die mit den wort "Bug" zu tun haben bzw. mir das als excel liste ausgeben?

 

[Joose]

Sinn von dem ganzen ist recht einfach erklärt

Ich habe zwar verstanden was du tun willst (so in etwa), aber den Sinn dahinter habe ich noch nicht erkennen können? Was bringt es mir zu sehen wie hoch die Wahrscheinlichkeit von einem Bug in Klasse XYZ ist?

Außerdem kann man das pauschal nicht einfach so festlegen das Bug XYZ mit Klasse dieser oder jener Klasse zu tun hat. Es gibt auch Bugs welche sich über mehrere Klassen hinweg ziehen und nicht eindeutig einer einzigen Klasse zugewiesen werden kann.

 

[martin1989]

sinn ist das ich die teststrategie einer software dann so ausrichten kann, dass ich mit den klassen beginne, die die höchste wahrscheinlichkeit für bugs aufweisen 😉

 

[martin1989]

Habe jetzt mal das ganze mit git und Junit versucht:

mit dem befehl:

git diff r4.10 r4.11 --name-only > patch.csv

bekomme ich die namen der geänderten klasen von einem zum anderen release.

Kann ich das jetzt noch irgendwie einschränken, dass nur klassenamen angezeigt werden wo die änderungen auf einem commit basiereten der das wort "bug" beinhaltet?



mit dem befehl git log --grep=bug werden ja mal alle commits angezeigt wo das wort bug vorkommt. wie kann ich dies jetzt auf den diff befehl anwerden?

EDIT: Denke folgender befehl ist das was ich suche:

git log r4.11..r4.12 --grep=bug --name-only --patience > print.csv

bin ich hier richtig?