Vorschlag: Umorganisation des CVS
-
- Image-Team
- Beiträge: 146
- Registriert: Dienstag 10. September 2002, 20:25
Vorschlag: Umorganisation des CVS
Ich habe mir lange überlegt, ob und wo ich diesen Beitrag überhaupt schreiben soll, habe mich aber dazu entschlossen, das jetzt zu machen. Da ich nicht, wie viele andere hier, nur meckern möchte, sondern auch mal überlegt habe, wie man die aktuelle Situation (siehe weiter unten) wieder in den Griff bekommen kann, möchte ich an dieser Stelle mal ein paar Vorschläge unterbreiten. Und das Argument, daß es bei solch einer Projektgröße nie machbar sein wird, daß alles stabil und immer compilierbar ist, zählt nicht, denn es gibt viele große Linux-Distributionen, die auch prima laufen. Ok, ich sehe ja ein, daß dahinter große Firmen stecken, die damit auch Geld verdienen, aber ganz so groß ist dieses Projekt dann auch mal wieder nicht.
Die aktuelle Situation
Da ich (noch) nicht sehr tief in diesem Projekt stecke folgt nun eine kleine Zusammenfassung der aktuellen Situation wie ich diese als Außenstehender sehe:
- Es ist zur Zeit nicht einfach, sich ein eigenes, aktuelles Image aus dem CVS zu bauen, da nicht alles durchcompiliert und man mindestens an einer Stelle im Makefile Änderungen machen muss, damit es wenigstens Compiliert
- Hat man ein fertiges Image, so läuft das alles andere, als gut (siehe dazu auch meinen Beitrag hier.
- Es existieren zwei verschiedene APIs (in Head und in Release), Neutrino benutzt die neue API, Enigma die alte. Deshalb wird sowohl im Head als auch im Release entwickelt
- Änderungen werden oft auch dann ins CVS eingecheckt, obwohl diese noch gar nicht richtig compilieren
Vorschlag für eine Verbesserung dieser Situation
Wie wäre es denn, wenn man die CVS-Struktur und die Eincheck-Gewohnheiten etwas ändern würde?
Ein Vorschlag: Es könnte mindestens drei verschiedene Zweige geben:
- Einen dev-Zweig: Hier könnte all das hinein, was man nach irgendwelchen Änderungen gerne gesichert hätte. Dieser Zweig sollte am besten gar nicht compilierbar sein, sondern einfach zur Sicherung und zum Austausch des Quellcodes dienen.
- Einen testing-Zweig: Sind die Entwickler der Meinung, daß der aktuelle Code compilierbar ist und so einigermaßen gut läuft, dann checken diese den Quellcode hier ein. Ziel des Zweiges ist, daß dieser immer compilierbar ist, damit sich die Benutzer, die Freude am Testen haben, immer die (fast) aktuelle Version holen können
- Einen stable-Zweig: Läuft die Version einer Datei bzw. eines Programms im testing-Zweig gut und stabil, d.h. es kamen keine Klagen irgendwelcher User, dann wird die Datei hier eingecheckt. Dieser Zweig sollte wirklich immer durchcompilieren und danach etwas sehr stabiles rauskommen (ist halt dann nicht immer das aktuellste, aber es läuft)
Doch wie realisiert man dann z.B. das mit der neuen und alten API? Hier ein Lösungsvorschlag: In stable könnte die alte API rein, in testing die neue (in stable könnte dann jeweils eine etwas ältere Version von Neutrino und Enigma rein, welche wirklich stabil laufen sollten) Entwickelt wird LOKAL auf den Rechnern der Entwickler und zwar natürlich immer in dem Zweig, welcher auf das Programm passt. Eingecheckt sollte aber IMMER in den Dev-Zweig werden, denn dieser sollte ja eh nicht compilieren.
Weitere Vorschläge
- Es könnten Meilensteine definiert werden, z.B.: Einmal in der Woche wird aus dem testing-Zweig ein Yadd/Image erstellt, einmal im Monat aus dem Stable-Zweig. So wüssten auch die Entwickler genau, was in welchen Yadd/Image von ihnen ist und bis wann Änderungen/Bugfixes spätestens fertig sein sollten, damit diese im neuen Yadd/Image vorhanden sind.
- Die Yadd/Images sollten direkt aus dem CVS ohne weitere Änderungen erstellbar sein, damit jeder nachvollziehen kann, wie diese erstellt wurden und sich ggf. selber das Image erstellen, indem er einfach den CVS-Stand eines bestimmten Datums auscheckt und selber compiliert.
- Im Forum könnten extra Teile für die drei Zweige aufgemacht werden, denn: Ein Yadd/Image entspricht ja genau einem CVS-Zweig von einem bestimmten Datum. So könnte dann jeder Fehler relativ schnell entdeckt werden (und es ist dann nicht mehr so wie früher, daß dann jeder einfach auf dem Ersteller des Images rumhackt).
- Es könnte auch ein Forums-Teil für mögliche gefundene Bugs aufgemacht werden, denn dann hätte man die ersten alle an einer Stelle und für jeden User sichtbar, damit dieser überprüfen kann, ob sein Problem vielleicht jemand anders auch hat, und zweitens weiß bestimmt auch kaum jemand, daß sowas wie ein Bug-Tracking-Tool existiert (mir kann auch keiner weiß machen, daß bisher nur 18 Bugs gefunden worden sind...) Die Bugs sollten dann jeweils aus anderen Teilen des Forums gesammelt und dort eingetragen werden, wenn das nicht direkt dort eingetragen wird.
Was haltet ihr davon? Ist alles, was ich schreibe nicht machbar und einfach sch... oder hört sich vielleicht etwas davon als realisierbar an?
Die aktuelle Situation
Da ich (noch) nicht sehr tief in diesem Projekt stecke folgt nun eine kleine Zusammenfassung der aktuellen Situation wie ich diese als Außenstehender sehe:
- Es ist zur Zeit nicht einfach, sich ein eigenes, aktuelles Image aus dem CVS zu bauen, da nicht alles durchcompiliert und man mindestens an einer Stelle im Makefile Änderungen machen muss, damit es wenigstens Compiliert
- Hat man ein fertiges Image, so läuft das alles andere, als gut (siehe dazu auch meinen Beitrag hier.
- Es existieren zwei verschiedene APIs (in Head und in Release), Neutrino benutzt die neue API, Enigma die alte. Deshalb wird sowohl im Head als auch im Release entwickelt
- Änderungen werden oft auch dann ins CVS eingecheckt, obwohl diese noch gar nicht richtig compilieren
Vorschlag für eine Verbesserung dieser Situation
Wie wäre es denn, wenn man die CVS-Struktur und die Eincheck-Gewohnheiten etwas ändern würde?
Ein Vorschlag: Es könnte mindestens drei verschiedene Zweige geben:
- Einen dev-Zweig: Hier könnte all das hinein, was man nach irgendwelchen Änderungen gerne gesichert hätte. Dieser Zweig sollte am besten gar nicht compilierbar sein, sondern einfach zur Sicherung und zum Austausch des Quellcodes dienen.
- Einen testing-Zweig: Sind die Entwickler der Meinung, daß der aktuelle Code compilierbar ist und so einigermaßen gut läuft, dann checken diese den Quellcode hier ein. Ziel des Zweiges ist, daß dieser immer compilierbar ist, damit sich die Benutzer, die Freude am Testen haben, immer die (fast) aktuelle Version holen können
- Einen stable-Zweig: Läuft die Version einer Datei bzw. eines Programms im testing-Zweig gut und stabil, d.h. es kamen keine Klagen irgendwelcher User, dann wird die Datei hier eingecheckt. Dieser Zweig sollte wirklich immer durchcompilieren und danach etwas sehr stabiles rauskommen (ist halt dann nicht immer das aktuellste, aber es läuft)
Doch wie realisiert man dann z.B. das mit der neuen und alten API? Hier ein Lösungsvorschlag: In stable könnte die alte API rein, in testing die neue (in stable könnte dann jeweils eine etwas ältere Version von Neutrino und Enigma rein, welche wirklich stabil laufen sollten) Entwickelt wird LOKAL auf den Rechnern der Entwickler und zwar natürlich immer in dem Zweig, welcher auf das Programm passt. Eingecheckt sollte aber IMMER in den Dev-Zweig werden, denn dieser sollte ja eh nicht compilieren.
Weitere Vorschläge
- Es könnten Meilensteine definiert werden, z.B.: Einmal in der Woche wird aus dem testing-Zweig ein Yadd/Image erstellt, einmal im Monat aus dem Stable-Zweig. So wüssten auch die Entwickler genau, was in welchen Yadd/Image von ihnen ist und bis wann Änderungen/Bugfixes spätestens fertig sein sollten, damit diese im neuen Yadd/Image vorhanden sind.
- Die Yadd/Images sollten direkt aus dem CVS ohne weitere Änderungen erstellbar sein, damit jeder nachvollziehen kann, wie diese erstellt wurden und sich ggf. selber das Image erstellen, indem er einfach den CVS-Stand eines bestimmten Datums auscheckt und selber compiliert.
- Im Forum könnten extra Teile für die drei Zweige aufgemacht werden, denn: Ein Yadd/Image entspricht ja genau einem CVS-Zweig von einem bestimmten Datum. So könnte dann jeder Fehler relativ schnell entdeckt werden (und es ist dann nicht mehr so wie früher, daß dann jeder einfach auf dem Ersteller des Images rumhackt).
- Es könnte auch ein Forums-Teil für mögliche gefundene Bugs aufgemacht werden, denn dann hätte man die ersten alle an einer Stelle und für jeden User sichtbar, damit dieser überprüfen kann, ob sein Problem vielleicht jemand anders auch hat, und zweitens weiß bestimmt auch kaum jemand, daß sowas wie ein Bug-Tracking-Tool existiert (mir kann auch keiner weiß machen, daß bisher nur 18 Bugs gefunden worden sind...) Die Bugs sollten dann jeweils aus anderen Teilen des Forums gesammelt und dort eingetragen werden, wenn das nicht direkt dort eingetragen wird.
Was haltet ihr davon? Ist alles, was ich schreibe nicht machbar und einfach sch... oder hört sich vielleicht etwas davon als realisierbar an?
-
- Erleuchteter
- Beiträge: 465
- Registriert: Mittwoch 14. August 2002, 20:45
Gut, nur wer macht die Arbeit?
Ausserdem ist der HEAD (bzw. rel_1_0_0 bei Enigma) bis auf die Treiber doch recht stable.
Wenn die Brainpower die hier in Vorschlaege fuer operationelle Veraenderungen gesteckt wird, in das Fixen der Treiberbugs gesteckt wuerde, haetten wie die ganze Diskussion nicht.
Leider ist es aber so, dass es an aktiven Devs mangelt, aber tonnenweise Vorschlaege kommen, womit sie noch ihre Zeit verbringen koennten.
Das beste Management hilft nicht, wenn das Produkt Muell ist.
Also mein Vorschlag: Beteiligt euch!
Ausserdem ist der HEAD (bzw. rel_1_0_0 bei Enigma) bis auf die Treiber doch recht stable.
Wenn die Brainpower die hier in Vorschlaege fuer operationelle Veraenderungen gesteckt wird, in das Fixen der Treiberbugs gesteckt wuerde, haetten wie die ganze Diskussion nicht.
Leider ist es aber so, dass es an aktiven Devs mangelt, aber tonnenweise Vorschlaege kommen, womit sie noch ihre Zeit verbringen koennten.
Das beste Management hilft nicht, wenn das Produkt Muell ist.
Also mein Vorschlag: Beteiligt euch!
-
- Image-Team
- Beiträge: 146
- Registriert: Dienstag 10. September 2002, 20:25
Ich würde mich gerne an dem Projekt beteiligen, ich weiß nur leider nicht wo ich mich melden soll und wo und was ich machen könnte. Mit C++ kenne ich mich leider nicht so toll aus und weiß nicht, wo jemand gebraucht werden könnte. Aber Interesse hätte ich schon. Zur Not könnte ich mich sogar in C++ einarbeiten, wenn mir jemand erklärt, was zu machen ist (und wie). Auf jeden Fall möchte ich das Projekt gerne mit meiner Hilfe unterstützen.
Und was meinst Du mit recht stable?
Habe vor ein paar Tagen mal den Head-Zweig compiliert. Nach dem compilieren läuft erst mal gar nichts, bis man drauf kommt, einen Link zu löschen. Danach funktioniert der Netzwerkzugriff auf die Box gar nicht und Neutrino stürzt andauernd ab, d.h. nach ein paar mal hin- und herschalten reagiert die Fernsteuerung nicht mehr. Wenn ich wüsste wie, hätte ichs schon längst behoben, kenne mich jedoch wie schon oben erwähnt noch nicht so doll aus.
Und was meinst Du mit recht stable?
Habe vor ein paar Tagen mal den Head-Zweig compiliert. Nach dem compilieren läuft erst mal gar nichts, bis man drauf kommt, einen Link zu löschen. Danach funktioniert der Netzwerkzugriff auf die Box gar nicht und Neutrino stürzt andauernd ab, d.h. nach ein paar mal hin- und herschalten reagiert die Fernsteuerung nicht mehr. Wenn ich wüsste wie, hätte ichs schon längst behoben, kenne mich jedoch wie schon oben erwähnt noch nicht so doll aus.
-
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
Mithilfe ist gerne gesehen.
Allerdings empfehle ich, Dir erstmal ein paar Gedanken zu machen, was Du machen möchtest.
Ansonsten, kannst Du gleich Arbeit bekommen: Es wird noch mind. ein Treiber-Knecht gesucht.
Profil:
- braindead,
- traced Microcontroller-Traffic am liebsten mit der Zunge,
- belastbar [ständig Aerger mit anderen Devs]...
- Hat Forums-Verbot(!) (wg. psychologische Belastung durch die Forums-Benutzer)
PS:
Nachtzuschläge können wir nicht bezahlen
Allerdings empfehle ich, Dir erstmal ein paar Gedanken zu machen, was Du machen möchtest.
Ansonsten, kannst Du gleich Arbeit bekommen: Es wird noch mind. ein Treiber-Knecht gesucht.
Profil:
- braindead,
- traced Microcontroller-Traffic am liebsten mit der Zunge,
- belastbar [ständig Aerger mit anderen Devs]...
- Hat Forums-Verbot(!) (wg. psychologische Belastung durch die Forums-Benutzer)
PS:
Nachtzuschläge können wir nicht bezahlen
-
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
-
- Image-Team
- Beiträge: 146
- Registriert: Dienstag 10. September 2002, 20:25
Gibt es denn irgendwo eine Übersicht, welche Bereiche es gibt und wo Leute gebraucht werden? Denn der Treiber-Bereich kommt für mich (vorerst) mal nicht in Frage, da ich wie schon oben geschrieben kaum Ahnung von C++ habe, reicht gerade mal für ein Hello World ProgrammMithilfe ist gerne gesehen.
Allerdings empfehle ich, Dir erstmal ein paar Gedanken zu machen, was Du machen möchtest.
Am meisten würde mich natürlich der Bereich Projektorganisation / CVS-Versionsverwaltung, Configuration Management, Qualitätssicherung usw. interessieren, denn ich kenne mich in diesen Bereichen ganz gut aus, weiß aber nicht, ob dort überhaupt wer gebraucht wird.
Alternativ könnte ich auch zum Tester werden, denn ein Image herstellen kann ich inzwischen und getestet habe ich auch schon mal für ein anders Projekt.
Edit:
Ich werde mich jetzt mal solange, bis ich was anderes zu tun bekommen habe, versuchen, ein Image für die Allgemeinheit zu erstellen.
Das ist sicherlich eine Gute Idee.ALexH hat geschrieben:
Ich werde mich jetzt mal solange, bis ich was anderes zu tun bekommen habe, versuchen, ein Image für die Allgemeinheit zu erstellen.
Zum einen solltest Du dich in die Image-Erstellung einarbeiten, damit Du weist, was zu machen ist.
Zum anderen solltest Du versuchen Mitstreiter zu suchen, die Dir beim Testen helfen, damit die Images auch auf allen Box-Varianten funktionieren.
Wenn Du einige Leute zusammen hast, solltest Du ein Verfahren überlegen, wie systematisch neue Images mit ordentlicher Qualität erstellt werden können.
Wenn Du was von Qualitätsmanagementverstehst, dürfte das Image-Erstellen für Dich der richtige Beitrag zum Projekt sein.
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
Hi,
Falls Du Tester suchst (Yadd waere gut) bin ich dabei mit meiner Phillips-Sat Box.
Viel Erfolg,
peter
--
Wir leben alle wie Robinson, wir warten auf Freitag.
das find' ich ja geil...gibt's also demnaechst ein AlexH-ImageALexH hat geschrieben:Ich werde mich jetzt mal solange, bis ich was anderes zu tun bekommen habe, versuchen, ein Image für die Allgemeinheit zu erstellen.
Falls Du Tester suchst (Yadd waere gut) bin ich dabei mit meiner Phillips-Sat Box.
Viel Erfolg,
peter
--
Wir leben alle wie Robinson, wir warten auf Freitag.
-
- Einsteiger
- Beiträge: 158
- Registriert: Freitag 9. November 2001, 00:00
-
- Einsteiger
- Beiträge: 281
- Registriert: Mittwoch 15. Mai 2002, 08:15
Also Testen kann ich auch gerne, Yadd oder Image wäre natürlich egal.
Testbox ist der Zeit die Philips 2xi, wenns an Sagem 1xi mangelt kann ich die 2 Boxen auch tauschen....
Ich könnte ausserdem einen kleinen Webspace zum Bereitstellen für die Allgemeinheit bereitstellen, aber mehr als 4 Images bringe ich nicht unter, sofern hier kein Platz bereitsteht?
Sepp
Testbox ist der Zeit die Philips 2xi, wenns an Sagem 1xi mangelt kann ich die 2 Boxen auch tauschen....
Ich könnte ausserdem einen kleinen Webspace zum Bereitstellen für die Allgemeinheit bereitstellen, aber mehr als 4 Images bringe ich nicht unter, sofern hier kein Platz bereitsteht?
Sepp
1. Box: Sagem 1xi
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
-
- Tuxboxer
- Beiträge: 2227
- Registriert: Freitag 24. Mai 2002, 10:38
-
- Einsteiger
- Beiträge: 281
- Registriert: Mittwoch 15. Mai 2002, 08:15
Wenn Platz da ist ist das natürlich optimal.
Ich denke daß ein Imagebereich, der Allgemein zugänglich ist, ideal wäre.
Es kann ja auch hier wie bei den Yadds von Homar "Fertige" und "Testversionen" geben.
Ob es das ultimative universal GTX/ENX/NOKIA/SAGEM/SAGEM/PHILIPS SAT und KABELIMAGE unbedingt geben muß ist ein anderes Thema.
Jede Box hat Ihre Fehler und eigenheiten.
Die Federvieh unterscheiden ja mal grundsätzlich zwischen GTX und ENX Images, und für die Philips kommen auch besonderheiten rein um das Statrbroblem zu "Besänftigen".
Wenn es viel viel mehr Aufwand ist die EierlegendeWollMilchSau zu erstellen als 2-4 Einzelimages die Boxoptimiert sind wäre das abzuwägen, aus Endusersicht zumindest. Schöner wäre natürlich 1 Image für alle....
Sepp
Ich denke daß ein Imagebereich, der Allgemein zugänglich ist, ideal wäre.
Es kann ja auch hier wie bei den Yadds von Homar "Fertige" und "Testversionen" geben.
Ob es das ultimative universal GTX/ENX/NOKIA/SAGEM/SAGEM/PHILIPS SAT und KABELIMAGE unbedingt geben muß ist ein anderes Thema.
Jede Box hat Ihre Fehler und eigenheiten.
Die Federvieh unterscheiden ja mal grundsätzlich zwischen GTX und ENX Images, und für die Philips kommen auch besonderheiten rein um das Statrbroblem zu "Besänftigen".
Wenn es viel viel mehr Aufwand ist die EierlegendeWollMilchSau zu erstellen als 2-4 Einzelimages die Boxoptimiert sind wäre das abzuwägen, aus Endusersicht zumindest. Schöner wäre natürlich 1 Image für alle....
Sepp
1. Box: Sagem 1xi
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
-
- Senior Member
- Beiträge: 1278
- Registriert: Mittwoch 5. September 2001, 00:00
-
- Einsteiger
- Beiträge: 281
- Registriert: Mittwoch 15. Mai 2002, 08:15
http://www.dbox2.info/download.php?catid=7
Hier sind die Yadds, und beim Link zum Upload ist neben vielen MP3s auch nützliches wie das Image, Skripte usw.
Sepp
Hier sind die Yadds, und beim Link zum Upload ist neben vielen MP3s auch nützliches wie das Image, Skripte usw.
Sepp
1. Box: Sagem 1xi
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
-
- Einsteiger
- Beiträge: 281
- Registriert: Mittwoch 15. Mai 2002, 08:15
Ein bischen Bier hat mann auch, der Link war natürlich total daneben. Irgendwie zeigt AOL manchmal nicht den link der aktuellen Seite an, wenn mehrere Fenster offen sind.
Ich habs gerade nochmals probiert, Bei Fensterwechsel wechselt die Eingabezeile mit der URL nicht mit, daher der Name Hase...
Tschuldigung, war wirklich keine Absicht!
Sepp
Ich habs gerade nochmals probiert, Bei Fensterwechsel wechselt die Eingabezeile mit der URL nicht mit, daher der Name Hase...
Tschuldigung, war wirklich keine Absicht!
Sepp
1. Box: Sagem 1xi
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver
2. Box: Philips 2xi (eine gute *g*)
3. Box: Glaxais easy-world (noch, nicht zu empfehlen!)
4. Box: Hyundai HSS820 Festplatten CI-Receiver