Am Sonntag, 22. Mai 2005 00:42 schrieb guettli:
Wenn es ein zentrale Versionsverwaltung (z.B Subversion) für alle Pakete geben würde, wäre eine Entwicklung sicherlich schneller.
Es gibt dazu bereits Alioth, basierend auf GForge, Nachfolger von SourceForge: http://alioth.debian.org/ Dort sind ein paar native Debianprojekte gehostet, und auch Paketdaten (pkg-*). Es kommt natürlich immer auf den Maintainer an. Es gibt welche, die schreien geradezu nach Hilfe, und solche, die alles allein machen wollen. Da hilft dann auch kein Subversion.
Nicht nur einmal habe ich einen kleinen Bug festgestellt, wollte den berichten und schaue voher im Bug-Tracking System nach. Dort hat den gleichen Bug schon jemand vor Wochen berichtet. Toll! Der Bug kann mit zwei oder drei Zeilen behoben werden, der Maintainer reagiert jedoch nicht. An dieser Stelle hört man dann meistens aus Faulheit auf, umgeht den Fehler und lässt die Sache auf sich beruhen.
Reaktionszeiten von ein paar Wochen sind nichts ungewöhnliches. Wenn der Maintainer gerade Prüfungen hat, dann hat er die eben. Es wurde ja schon etwas in die Richtung optimiert: Es gibt Co-Maintainer, und es gibt (immer mehr) Paket-Teams, z.B. bei KDE. Gerade im Basissystem frickeln die Leute aber nach wie vor jeder für sich herum, das stimmt schon.
Bei einer zentralen Quelltextverwaltung könnte man, wenn man einchecken darf, den Fehler gleich beheben.
Siehe Alioth.
Die binary Pakete sollten entsprechend nur aus der Versionsverwaltung gebaut werden.
Das wäre dann die Frage, ob die Patches, die dort jeder committen darf, auch bei $USER als Paket ankommen sollen. Wenn es aber nur um Patches geht, sind die auch jetzt schon möglich (über das BTS). Dass dieses mal (designtechnisch) generalüberholt werden muss, ist eine andere Frage :-)
Was aber durchaus oft problematisch ist sind Binär-Uploads, die dann Reste vom Rechner des Maintainers enthalten. Dafür fordern ja einige Source-Only-Uploads. Andere lehnen das ab mit der Begründung, dann würden die Maintainer faul und prüften es nicht mehr lokal auf Fehler, sondern schauen erstmal ob es auf den Servern automatisch durchcompiliert oder nicht.
Als Kompromiss wäre möglich, die Erstellung des lokalen Paketes mit pbuilder durchzutesten, und dann einen Source-Only-Upload durchzuführen. Ein weiteres kleines Problem, was sich dabei ergibt, ist dass die Build-Server aus historischen Gründen die Pakete etwas anders bauen als wie es logisch machbar (und vereinfachbar) wäre. Nunja.
Der nächste Schritt wäre es, wenn man automatisiert (nächtlich) Unittest durchführt und somit kritische Fehler schnell mitbekommt. Viele Upstream Entwickler bieten ein "make test" an.
Ja, wobei das nur begrenzt sinnvoll ist. Wenn ein Videocodec auf einer komischen Architektur die Farben vertauscht, kann man das nur schwer mit einer Testroutine erkennen lassen, denn diese wird mit nahezu derselben Wahrscheinlichkeit diesen Fehler auch aufweisen.
Josef