Revision 27cb9c6a
Von Sven Schöling vor etwa 12 Jahren hinzugefügt
| doc/release_management.txt | ||
|---|---|---|
| 20 | 20 |
1. KONSISTENZ DES PROGRAMMS |
| 21 | 21 |
=========================== |
| 22 | 22 |
|
| 23 |
* Testlauf t/test.sh |
|
| 24 |
|
|
| 25 |
- Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen): |
|
| 26 |
o bin/mozilla/ar.pl contains at least 190 html tags. |
|
| 27 |
o bin/mozilla/ic.pl contains at least 130 html tags. |
|
| 28 |
o bin/mozilla/ap.pl contains at least 183 html tags. |
|
| 29 |
o bin/mozilla/admin.pl DOES NOT use proper system or exec calls |
|
| 30 |
- Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus. |
|
| 31 |
TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde. |
|
| 32 |
TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die |
|
| 33 |
sollten vor einem Release zumindest durchlaufen. |
|
| 34 |
TODO: Evtl eine Klasse von Releasetests einführen) |
|
| 35 |
|
|
| 36 |
* Testinstallation aus dem git mit neuer auth Datenbank. |
|
| 37 |
|
|
| 38 |
- Änderungen die die auth Systeme betreffen zerreissen gerne mal die initiale |
|
| 39 |
Installation. |
|
| 40 |
|
|
| 41 |
* Testupgrade auf einer Vorversion. |
|
| 42 |
|
|
| 43 |
- Dito nur mit Upgradescripten. Fehlerhafte Abhängigkeiten können dazu |
|
| 44 |
führen, dass Upgradescripte nicht in der richtigen Reihenfolge ausgeführt |
|
| 45 |
werden, was bei inkrementellem Testen nicht auffällt. |
|
| 46 |
|
|
| 23 | 47 |
* Freeze auf der Mailingliste ansagen. |
| 24 | 48 |
|
| 25 | 49 |
- Featurefreeze für beta |
| ... | ... | |
| 153 | 177 |
|
| 154 | 178 |
t/test.sh |
| 155 | 179 |
|
| 156 |
- Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen): |
|
| 157 |
o bin/mozilla/ar.pl contains at least 190 html tags. |
|
| 158 |
o bin/mozilla/ic.pl contains at least 130 html tags. |
|
| 159 |
o bin/mozilla/ap.pl contains at least 183 html tags. |
|
| 160 |
o bin/mozilla/admin.pl DOES NOT use proper system or exec calls |
|
| 161 |
- Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus. |
|
| 162 |
TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde. |
|
| 163 |
TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die |
|
| 164 |
sollten vor einem Release zumindest durchlaufen. |
|
| 165 |
TODO: Evtl eine Klasse von Releasetests einführen) |
|
| 180 |
Siehe oben für mögliche Ergebnisse. |
|
| 166 | 181 |
|
| 167 | 182 |
* Alle Änderungen einchecken. |
| 168 | 183 |
|
Auch abrufbar als: Unified diff
Installation aus git und einer Vorversion ins releasemanagement übernommen