Entwickler.HowToReportBugs History

Hide minor edits - Show changes to markup

 
 
April 01, 2011, at 10:03 PM by tthelen -
Added lines 1-2:

(:redirect 'http://docs.studip.de/develop/Entwickler/HowToReportBugs':)

 
 
August 12, 2010, at 09:29 AM by nimuelle -
Added lines 126-128:
functest?Funktionstest aus Anwendersicht-Review erwünscht
functest+Funktionstest aus Anwendersicht-Review positiv
functest-Funktionstest aus Anwendersicht-Review negativ, d.h. Veto des Verantwortlichen
 
 
June 15, 2010, at 10:03 PM by mlunzena -
Changed lines 122-125 from:
security-Security-Review negativ, d.h. Veto des Verantwortlichen
to:
security-Security-Review negativ, d.h. Veto des Verantwortlichen
devdoc?Entwicklerdokumentations-Review erwünscht
devdoc+Entwicklerdokumentations-Review positiv
devdoc-Entwicklerdokumentations-Review negativ, d.h. Veto des Verantwortlichen
 
 
April 30, 2010, at 02:07 PM by eludwig -
Changed line 91 from:

Mir der Version wird erfaßt, ob sich ein Ticket auf das offizielle Stud.IP-Release bezieht (trunk) oder auf eine spezifische Standortversion von Stud.IP (studip-os o.ä.). Derzeit gibt es die folgenden Versionsbezeichner:

to:

Mit der Version wird erfaßt, ob sich ein Ticket auf das offizielle Stud.IP-Release bezieht (trunk) oder auf eine spezifische Standortversion von Stud.IP (studip-os o.ä.). Derzeit gibt es die folgenden Versionsbezeichner:

 
 
April 30, 2010, at 01:59 PM by eludwig -
Deleted line 12:
Changed lines 15-16 from:
to:
Added lines 49-54:

Fehlerbericht via E-Mail

Alternativ können Fehler auch per Mail an die Adresse studip-users@lists.sourceforge.net berichtet werden. Diese landen allerdings nicht automatisch in unserem Stud.IP-Ticketsystem, es kann daher gelegentlich passieren, daß diese längere Zeit unbearbeitet sind oder sogar wieder ganz in Vergessenheit geraten.

Daher sollten Fehler wenn möglich nicht via E-Mail berichtet werden, sondern über den unter 1.1 oder 1.2 genannten Weg.

 
 
April 30, 2010, at 01:42 PM by eludwig -
Changed line 111 from:
review?Code-Review notwendig
to:
review?Code-Review erwünscht
Changed line 114 from:
security?Security-Review notwendig
to:
security?Security-Review erwünscht
 
 
April 30, 2010, at 01:41 PM by eludwig -
Changed lines 83-84 from:

Version

to:

Version

Changed lines 94-95 from:

Cc

to:

Cc

Changed lines 98-99 from:

Priority

to:

Priority

Changed lines 102-103 from:

Component

to:

Component

Changed line 106 from:

Keywords

to:

Keywords

 
 
April 30, 2010, at 01:40 PM by eludwig -
Changed lines 26-27 from:

Der normale Weg, einen Fehler in Stud.IP zu melden, ist die Verwendung des entsprechenden Formulars in der Veranstaltung "Bugboard (BIESTs)" im Entwickler- und Anwenderforum. Voraussetzung dafür ist ein Account im Entwickler- und Anwenderforum (z.B. durch freie Registierung oder Shibboleth-Login). Der Begriff "BIEST" steht dabei für Bug und Inkonsitenz Erkennung für Stud.IP.

to:

Der normale Weg, einen Fehler in Stud.IP zu melden, ist die Verwendung des entsprechenden Formulars in der Veranstaltung "Bugboard (BIESTs)" im Entwickler- und Anwenderforum. Voraussetzung dafür ist ein Account im Entwickler- und Anwenderforum (z.B. durch freie Registierung oder Shibboleth-Login). Der Begriff "BIEST" steht hier für Bug und Inkonsitenz Erkennung für Stud.IP.

Changed line 30 from:
  1. Anmelden im Entwickler- und Anwenderforum
to:
  1. Anmelden im Entwickler- und Anwenderforum
Changed line 43 from:
  1. Anmelden im Trac (falls noch nicht geschehen)
to:
  1. Anmelden im Trac (falls noch nicht geschehen)
Changed lines 52-53 from:

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten. Verbesserungsvorschläge sollten (von Ausnahmefällen abgesehen) nicht ohne vorherige Diskussion ins Trac eingetragen werden.

to:

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten. Verbesserungsvorschläge sollten (von Ausnahmefällen abgesehen) nicht ohne vorherige Diskussion ins Trac eingetragen werden.

Changed lines 79-80 from:

Tickets, die als WONTFIX, INVALID oder DUPLICATE geschlossen werden, dürfen keinem Milestone zugewiesen sein.

to:

Tickets, die als INVALID, WONTFIX, DUPLICATE oder WORKSFORME geschlossen werden, dürfen keinem Milestone zugewiesen sein.

Changed lines 110-116 from:
  • review?: Code-Review notwendig
  • review+: Code-Review positiv
  • review-: Code-Review negativ, d.h. Veto des Verantwortlichen
  • security?: Security-Review notwendig
  • security+: Security-Review positiv
  • security-: Security-Review negativ, d.h. Veto des Verantwortlichen
to:
review?Code-Review notwendig
review+Code-Review positiv
review-Code-Review negativ, d.h. Veto des Verantwortlichen
security?Security-Review notwendig
security+Security-Review positiv
security-Security-Review negativ, d.h. Veto des Verantwortlichen
 
 
April 30, 2010, at 12:47 PM by eludwig -
Changed lines 11-12 from:

Fur die Meldung von Fehlern in Stud.IP gibt es verschiedene Wege:

to:

Für die Meldung von Fehlern in Stud.IP gibt es verschiedene Wege:

Changed lines 17-18 from:

Bitte geben Sie in jedem Fall unbedingt an:

to:

Bitte geben Sie in jedem Fall unbedingt an:

Added lines 24-36:

Fehlerbericht über das Bugboard

Der normale Weg, einen Fehler in Stud.IP zu melden, ist die Verwendung des entsprechenden Formulars in der Veranstaltung "Bugboard (BIESTs)" im Entwickler- und Anwenderforum. Voraussetzung dafür ist ein Account im Entwickler- und Anwenderforum (z.B. durch freie Registierung oder Shibboleth-Login). Der Begriff "BIEST" steht dabei für Bug und Inkonsitenz Erkennung für Stud.IP.

Zum Eintragen eines neuen Fehlerberichts gehen Sie folgendermaßen vor:

  1. Anmelden im Entwickler- und Anwenderforum
  2. Die Veranstaltung "Bugboard (BIESTs)" aufrufen (ggf. als Teilnehmer eintragen).
  3. Dort den Reiter "BIESTer" in der Navigation auswählen.
  4. Auf dieser Seite den Link "BIEST melden" in der Navigation anklicken.
  5. Im Formular eine kurze Zusammenfassung und eine längere Beschreibung des Fehlers eingeben.
  6. Das Formular absenden.
Changed lines 44-53 from:
  1. den Punkt "New Ticket" in der Navigation auswählen
  2. Im Formular eine kurze Zusammenfassung und eine längere Beschreibung des Fehlers eingeben
  3. unter "Component" eine passende Kompontente auswählen (oder auf der Voreinstellung "Stud.IP allgemein" lassen)
  4. die anderen Felder auf der Voreinstellung belassen
  5. das Formular absenden

Wie berichte ich einen Verbesserungsvorschlag

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten.

to:
  1. Dort den Punkt "New Ticket" in der Navigation auswählen.
  2. Im Formular eine kurze Zusammenfassung und eine längere Beschreibung des Fehlers eingeben.
  3. Unter "Component" eine passende Kompontente auswählen (oder auf der Voreinstellung "Stud.IP allgemein" lassen).
  4. Alle anderen Felder auf der Voreinstellung belassen.
  5. Das Formular absenden.

Wie berichte ich einen Verbesserungsvorschlag?

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten. Verbesserungsvorschläge sollten (von Ausnahmefällen abgesehen) nicht ohne vorherige Diskussion ins Trac eingetragen werden.

Changed lines 56-57 from:

Dieser Abschnitt ist für Entwickler gedacht, die im Umgang mit dem Trac schon etwas Erfahrung gesammelt haben und Tickets (d.h. Fehlerberichte oder konkrete Verbesserungsvorschläge) bearbeiten wollen.

to:

Dieser Abschnitt ist für Entwickler gedacht, die im Umgang mit dem Trac schon etwas Erfahrung gesammelt haben und Tickets - d.h. Fehlerberichte oder konkrete Verbesserungsvorschläge - bearbeiten wollen.

Changed lines 63-64 from:
  • Lifters: eine langfristig angelegte Überarbeitung, muß zuvor von der Core-Group abgestimmt werden (trunk)
  • StEP: ein Verbesserungsvorschlag, muß zuvor von der Core-Group abgestimmt werden (trunk)
to:
  • Lifters: eine langfristig angelegte Überarbeitung, muß zuvor von der Core-Group abgestimmt werden (trunk)
  • StEP: ein Verbesserungsvorschlag, muß zuvor von der Core-Group abgestimmt werden (trunk)
Added line 66:
Changed lines 73-79 from:

Über die Milestones wird verwaltet, welche Tickets für welches Stud.IP-Release erfolgreich geschlossen worden sind oder noch erledigt werden müssen. Dabei gelten folgende Regeln:

  • Der Milestone sollte nur von der Person bearbeitet werden , der das Ticket zugewiesen ist (oder einem der Release-Verantwortlichen).
  • Offene Tickets sollten nur dann einen Milestone besitzen, wenn es erforderlich ist, sie für ein entsprechendes Release zu erledigen (BIEST) oder vom Ersteller zugesagt wurde, eine entsprechende Verbesserung bis dahin einzubauen (StEP, TIC).
  • Der Milestone gibt die kleinste Version von Stud.IP an, welche die Korrektur (bzw. Verbesserung) enthält, das ist bei einem BIEST in der Regel der aktuelle Release-Branch.
  • Tickets, die als WONTFIX, INVALID oder DUPLICATE geschlossen werden, dürfen keinem Milestone zugewiesen sein.
to:

Ein Milestone im Trac entspricht jeweils einem offiziellen Release von Stud.IP (wie 1.11.1 oder 1.12). Über die Milestone-Angabe im Ticket wird verwaltet, welche Tickets für welches Stud.IP-Release erfolgreich geschlossen worden sind oder noch erledigt werden müssen. Nur Tickets, die sich auf das offizielle Release beziehen, haben einen Milestone, und der Milestone sollte nur von der Person bearbeitet werden, der das Ticket zugewiesen ist (oder einem der Release-Verantwortlichen). Dabei gelten folgende Regeln:

BIEST
Ein offenes BIEST hat keinen Milestone. Wenn das BIEST geschlossen wird, gibt der Milestone die erste Version von Stud.IP an, die diese Korrektur enthält, das ist in der Regel der jeweils aktuelle Release-Branch.
StEP, TIC
Der Milestone ist die Version, für die der StEP bzw. TIC eingebaut werden soll.
Lifters
Ein Lifters hat keinen Milestone.

Tickets, die als WONTFIX, INVALID oder DUPLICATE geschlossen werden, dürfen keinem Milestone zugewiesen sein.

Changed lines 85-87 from:

Mir der Version wird erfaßt, ob sich ein Ticket auf das offizielle Stud.IP-Release bezieht (trunk) oder auf eine spezifische Standortversion von Stud.IP (studip-os o.ä.).

Wenn eine weitere Standortversion in die Auswahlliste im Trac aufgenommen werden soll, wenden Sie sich bitte an einen der Trac-Administratoren.

to:

Mir der Version wird erfaßt, ob sich ein Ticket auf das offizielle Stud.IP-Release bezieht (trunk) oder auf eine spezifische Standortversion von Stud.IP (studip-os o.ä.). Derzeit gibt es die folgenden Versionsbezeichner:

  • trunk: das offizielle Stud.IP-Release
  • studip-os: das Stud.IP der Uni Osnabrück
  • studip-fhos: das Stud.IP der FH Osnabrück
  • forschdb-os: die Forschungsdatenbank der Uni Osnabrück

Wenn eine weitere Standortversion in die Auswahlliste im Trac aufgenommen werden soll, wenden Sie sich bitte an einen der Trac-Administratoren (Elmar Ludwig, André Noack, Marcus Lunzenauer).

Cc

Hier können weitere Personen eingetragen werden, die über den Stand des Tickets informiert werden sollen. Eingetragen werden können Account-Namen und/oder Mail-Adressen (jeweils durch Komma getrennt).

Priority

Über das Feld Priority kann der Besitzer des Tickets (d.h. der dem Ticket zugewiesene Entwickler) notieren, wie wichtig die Korrektur eines bestimmten Problems ist. Die Voreinstellung ist hier "normal".

Component

Die Komponente gibt den Bereich von Stud.IP an, auf das sich das Ticket beziegt. Es gibt eine vorgegebene Liste von Komponenten wie "Forum", "Nachrichten / Kontakte" oder "Veranstaltungen". Alles, was nicht in eine der Standardkategorieren hineingehört, sollte unter "Stud.IP allgemein" eingetragen werden. Das ist auch die Voreinstellung.

Keywords

Über die Standardattribute hinausgehende Markierungen an einem Ticket werden über Keywords abgebildet. Derzeit werden folgende Keywords verwendet:

  • review?: Code-Review notwendig
  • review+: Code-Review positiv
  • review-: Code-Review negativ, d.h. Veto des Verantwortlichen
  • security?: Security-Review notwendig
  • security+: Security-Review positiv
  • security-: Security-Review negativ, d.h. Veto des Verantwortlichen
 
 
April 29, 2010, at 04:54 PM by eludwig -
Changed lines 19-26 from:
  1. In welcher Stud.IP-Version bzw. an welchem Standort tritt der Fehler auf? (z.B.: Version 1.11, Uni Göttingen)
  2. Welchen Browser in welcher Version verwenden Sie? (z.B.: Internet Explorer 7)
  3. In welcher Rolle sind Sie im System unterwegs? (z.B. "Dozent")
  4. Beschreiben Sie möglichst genau, was unter welchen Umständen getan werden muß, um den Fehler zu reproduzieren.

Wie bereichte ich einen Verbesserungsvorschlag

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten.

to:
  • In welcher Stud.IP-Version bzw. an welchem Standort tritt der Fehler auf? (z.B.: Version 1.11, Uni Göttingen)
  • Welchen Browser in welcher Version verwenden Sie? (z.B.: Internet Explorer 7)
  • In welcher Rolle sind Sie im System unterwegs? (z.B. "Dozent")
  • Beschreiben Sie möglichst genau, was unter welchen Umständen getan werden muß, um den Fehler zu reproduzieren.

Fehlerbericht über das Trac

Für etwas erfahrene Entwickler und Anwender gibt es auch die Möglichkeit, einen Fehlerbericht direkt als "Ticket" in das Trac einzutragen. Voraussetzung dafür ist ein Account im Entwickler- und Anwenderforum, der als Teilnehmer in die Veranstaltung "Bugboard (BIESTs)" eingetragen ist. Mit diesem Account kann man sich dann auch im Trac anmelden.

Zum Eintragen eines neuen Tickets gehen Sie folgendermaßen vor:

  1. Anmelden im Trac (falls noch nicht geschehen)
  2. den Punkt "New Ticket" in der Navigation auswählen
  3. Im Formular eine kurze Zusammenfassung und eine längere Beschreibung des Fehlers eingeben
  4. unter "Component" eine passende Kompontente auswählen (oder auf der Voreinstellung "Stud.IP allgemein" lassen)
  5. die anderen Felder auf der Voreinstellung belassen
  6. das Formular absenden

Wie berichte ich einen Verbesserungsvorschlag

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten.

Verwaltung von Tickets im Trac

Dieser Abschnitt ist für Entwickler gedacht, die im Umgang mit dem Trac schon etwas Erfahrung gesammelt haben und Tickets (d.h. Fehlerberichte oder konkrete Verbesserungsvorschläge) bearbeiten wollen.

Typen von Tickets

Es gibt folgende Ticket-Typen:

  • BIEST: ein Fehler im offiziellen Release (trunk)
  • Lifters: eine langfristig angelegte Überarbeitung, muß zuvor von der Core-Group abgestimmt werden (trunk)
  • StEP: ein Verbesserungsvorschlag, muß zuvor von der Core-Group abgestimmt werden (trunk)
  • TIC: ein "kleiner" Verbesserungsvorschlag (trunk)
  • defect: ein Fehler in einer speziellen Standortversion
  • enhancement: ein Verbesserungsvorschlag für eine spezielle Standortversion
  • task: ein nicht codebezogenes Ticket (Update des Trac o.ä.)

Milestone

Über die Milestones wird verwaltet, welche Tickets für welches Stud.IP-Release erfolgreich geschlossen worden sind oder noch erledigt werden müssen. Dabei gelten folgende Regeln:

  • Der Milestone sollte nur von der Person bearbeitet werden , der das Ticket zugewiesen ist (oder einem der Release-Verantwortlichen).
  • Offene Tickets sollten nur dann einen Milestone besitzen, wenn es erforderlich ist, sie für ein entsprechendes Release zu erledigen (BIEST) oder vom Ersteller zugesagt wurde, eine entsprechende Verbesserung bis dahin einzubauen (StEP, TIC).
  • Der Milestone gibt die kleinste Version von Stud.IP an, welche die Korrektur (bzw. Verbesserung) enthält, das ist bei einem BIEST in der Regel der aktuelle Release-Branch.
  • Tickets, die als WONTFIX, INVALID oder DUPLICATE geschlossen werden, dürfen keinem Milestone zugewiesen sein.

Wichtig: Der Milestone gibt nicht an, in welcher Version der Fehler aufgetreten ist. Das sollte Teil des Beschreibungstextes sein.

Version

Mir der Version wird erfaßt, ob sich ein Ticket auf das offizielle Stud.IP-Release bezieht (trunk) oder auf eine spezifische Standortversion von Stud.IP (studip-os o.ä.).

Wenn eine weitere Standortversion in die Auswahlliste im Trac aufgenommen werden soll, wenden Sie sich bitte an einen der Trac-Administratoren.

 
 
April 29, 2010, at 03:55 PM by eludwig -
Added lines 1-26:

< Überblick | Entwicklungs-HOWTO | Entwicklungssystem aufsetzen >

Entwicklungs-HOWTO: Fehler berichten

(:toc:)

Für Meldung und Verwaltung von Fehlern wird das Trac auf dem Entwicklungsserver verwendet. Dort sind alle bekannten und behobenen Fehler dokumentiert, und auch die Planung für die zukünftigen Stud.IP-Releases wird dort organisiert.

Wie berichte ich einen Fehler?

Fur die Meldung von Fehlern in Stud.IP gibt es verschiedene Wege:

  • per E-Mail an studip-users@lists.sourceforge.net
  • über das Formular in der Veranstaltung Bugboard (BIESTs) im Entwickler- und Anwenderforum (Registrierung erforderlich)
  • direkt über ein Formular im Trac (Registrierung im Entwickler- und Anwenderforum erforderlich)

Bitte geben Sie in jedem Fall unbedingt an:

  1. In welcher Stud.IP-Version bzw. an welchem Standort tritt der Fehler auf? (z.B.: Version 1.11, Uni Göttingen)
  2. Welchen Browser in welcher Version verwenden Sie? (z.B.: Internet Explorer 7)
  3. In welcher Rolle sind Sie im System unterwegs? (z.B. "Dozent")
  4. Beschreiben Sie möglichst genau, was unter welchen Umständen getan werden muß, um den Fehler zu reproduzieren.

Wie bereichte ich einen Verbesserungsvorschlag

Die erste Anlaufstelle für Erweiterungs- oder Verbesserungsvorschläge sollte das Forum der Veranstaltung Developer-Board im Entwickler- und Anwenderforum sein. Dort kann man mit den Stud.IP-Entwicklern diskutieren, ob und ggf. in welcher Forum die eigenen Ideen umgesetzt werden könnten.

 

 

Source: Basis-Wiki-Hilfe | Last change: April 01, 2011, at 10:03 PM, tthelen | Local view: Basis-Hilfe