Hi
Da die Frage ja eigentlich eher prinzipiellen Charakter hat: Vielleicht
hilft's ja:
Guido Ostkamp schrieb:
>> Das immer wieder neu Auflegen eines release candidate verschlingt auch
>> resourcen ohne Ende in den QA Teams und an anderen Stellen haben wir
>> Abhaengigkeiten (releases von Linuxdistros, press releases, security
>> patches) die nicht ein Schieben mit offenem Ende erlauben.
>
> zusammengefaßt kann man daraus doch nur eines ableiten: Termin geht vor
> Qualität - sehr bedauerlich.
>
> Wenn schon beim Test des ersten(!) RC die Meinung vertreten wird, daß
> Korrekturen nun wg. Termindrucks nicht mal für Crashes, die außerdem
> noch eine Regression darstellen, mehr drin sind, frage ich mich
> ernsthaft, wozu man die RCs dann überhaupt macht.
Es gibt da ein paar Regeln, die sich das Projekt gegeben hat.
1.) IMHO ist das ein P2 issue ("Crashs or freezes during normal
operations of the application) - und für den gilt:
2,) Issues with this priority must be fixed before the target release
(see Target milestone), which usually is the next major release, and
should be dealt with as soon as possible.
Not fixing them for the target release is not acceptable.
Aus: http://qa.openoffice.org/ooQAReloaded/Docs/QA-Reloaded-ITguide.html
Leider kann ich da aber nirgendwo finden, was als Showstopper betrachtet
werden soll (ich bin aber ziemlich sicher, dass ich da schon mal was
dazu gelesen habe). Das wäre also mal auszudiskutieren und vor allem: In
den Prozessbeschreibungen zu ergänzen.
Vielleicht richtet Ihr Eure Mühen eher darauf, bevor diese ganze
Diskussion wieder mal verpufft und nur unzufrieden Menschen und
vergeudete Zeit zurücklässt? Nur so als Vorschlag ;-)
--
Mit freundlichen Grüßen
Uwe Altmann
OpenOffice.org auf dem Mac:
http://porting.openoffice.org/mac/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
