Hallo,
Ich bin kein Debian-Entwickler und verfolge die aktuellen Diskussionen auch nicht regelmäßig. Da ich jedoch täglich Software in einem kleinen Team erstelle, denke ich, etwas Erfahrung zu haben.
Da im Debian-Wiki über die Umstrukturierung des Projekts nachgedacht wird, habe ich mir auch einmal par Gedanken gemacht. Ich schreibe erstmal hier, da in der lug-dd einige Debian-Entwickler sind.
Wenn es ein zentrale Versionsverwaltung (z.B Subversion) für alle Pakete geben würde, wäre eine Entwicklung sicherlich schneller.
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.
Bei einer zentralen Quelltextverwaltung könnte man, wenn man einchecken darf, den Fehler gleich beheben.
Die binary Pakete sollten entsprechend nur aus der Versionsverwaltung gebaut werden.
Den bisherigen Ansatz, dass für ein Paket meist ein Entwickler zuständig ist, wäre damit aufgebrochen.
BSD oder gentoo möchte ich nicht nehmen, da ich mit Debian eigentlich zufrieden bin.
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.
Was denkt ihr darüber?
Thomas
* guettli guettli@thomas-guettler.de [2005-05-22 06:56:02]: [Zentrale Versionsverwaltung für Debian]
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.
Bei einer zentralen Quelltextverwaltung könnte man, wenn man einchecken darf, den Fehler gleich beheben.
Das Problem ist und bleibt, dass es schwer wird das Ganze dann noch sicher zu halten. Bis jetzt braucht man ja nur den Maintainern vertrauen bzw. deren gpg Schlüssel signiert zu haben. Wenn ein Subversion eingerichtet würde, in dem mehr Leute Schreibrechte haben, hätte man ein massives Problem, weil man nicht mehr ohne weiteres dem dort hinterlegten Code trauen könnte, es sei denn man vergibt die Zugänge nur nach ganz bestimmten, harten Bedingungen.
Die binary Pakete sollten entsprechend nur aus der Versionsverwaltung gebaut werden.
Den bisherigen Ansatz, dass für ein Paket meist ein Entwickler zuständig ist, wäre damit aufgebrochen.
BSD oder gentoo möchte ich nicht nehmen, da ich mit Debian eigentlich zufrieden bin.
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.
Automatisierte Tests wären sicherlich hilfreich.
Ich bin der Meinung, dass das vorhandene System mit Maintainern bestehen sollte. Es hat sich über längere Zeit bewährt und es ist -in meinen Augen- kein driftiger Grund zu sehen warum man an der Stelle herumschrauben sollte. An BSD oder Gentoo möchte ich mich nicht orientieren, da beide Projekte erstens andere Philosophien[0] und zweitens ganz andere Probleme haben.
[0] Wird das jetzt so geschrieben (ich habe es mit zwei "f" probiert, aber da sah es noch verbotener aus).
On Sunday 22 May 2005 07:06, Steffen Liebergeld wrote:
- guettli guettli@thomas-guettler.de [2005-05-22 06:56:02]:
[Zentrale Versionsverwaltung für Debian]
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.
Bei einer zentralen Quelltextverwaltung könnte man, wenn man einchecken darf, den Fehler gleich beheben.
Das Problem ist und bleibt, dass es schwer wird das Ganze dann noch sicher zu halten. Bis jetzt braucht man ja nur den Maintainern vertrauen bzw. deren gpg Schlüssel signiert zu haben. Wenn ein Subversion eingerichtet würde, in dem mehr Leute Schreibrechte haben, hätte man ein massives Problem, weil man nicht mehr ohne weiteres dem dort hinterlegten Code trauen könnte, es sei denn man vergibt die Zugänge nur nach ganz bestimmten, harten Bedingungen.
Subversion kann man so konfigurieren, dass die Nutzer nur auf bestimmte Verzeichnisse Zugriff haben (zumindest, wenn man WebDAV verwendet).
Es ist auch denkbar Subversion um Signaturen zu erweitern - das sollte sogar leichter sein, als die Verteilung durch svk.
Konrad
On Sun, May 22, 2005 at 07:06:32AM +0200, Steffen Liebergeld wrote:
- guettli guettli@thomas-guettler.de [2005-05-22 06:56:02]:
[Zentrale Versionsverwaltung f?r Debian]
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.
Bei einer zentralen Quelltextverwaltung k?nnte man, wenn man einchecken darf, den Fehler gleich beheben.
Das Problem ist und bleibt, dass es schwer wird das Ganze dann noch sicher zu halten. Bis jetzt braucht man ja nur den Maintainern vertrauen bzw. deren gpg Schl?ssel signiert zu haben. Wenn ein Subversion eingerichtet w?rde, in dem mehr Leute Schreibrechte haben, h?tte man ein massives Problem, weil man nicht mehr ohne weiteres dem dort hinterlegten Code trauen k?nnte, es sei denn man vergibt die Zug?nge nur nach ganz bestimmten, harten Bedingungen.
Warum sollte das Probleme geben? Bei NetBSD.org funktioniert das doch auch. Klar sollte sein, dass trotz der Verwaltung ueber CVS/SVN nur vertrauenswuerdige Maintainer Schreibrechte erhalten. Durch zentrales Bugtracking und damit verbundene offene Mailinglisten werden gemeldete Bugs oeffentlich diskutiert. Die Zustaendigkeit klaert sich so sehr schnell. Sollte der 'eigentlich' zustaendige Entwickler gerade verhindert sein oder sich nicht melden, kann in den meisten Faellen auch ein anderer die entsprechenden Fixes commiten. Alles in allem ein sehr transparenter Prozess - und mal ist niemals vom Wohlwollen eines bestimmten Maintainers abhaengig. Das selbe Prinzip kommt auch bei pkgsrc.org zum Einsatz, dem Softwareverteilungssystem von NetBSD.
Sonnige Gruesse von Matthias
On Sun, May 22, 2005 at 12:16:22PM +0200, Matthias Petermann wrote:
Klar sollte sein, dass trotz der Verwaltung ueber CVS/SVN nur vertrauenswuerdige Maintainer Schreibrechte erhalten.
Wieviel Leute mit Schreibrechten gibt es bei NetBSD? Wenn ich auf http://www.netbsd.org/People/ richtig zähle: weit unter 100. Debian hat flüssiger (als heute) funktioniert, als es schon weit größer war. Heute ist es eben riesig und das macht manches schwieriger, aber wie bereits geschrieben: beitragen kann jeder, der möchte.
Viele Grüße, Torsten
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
On Sun, May 22, 2005 at 11:30:13AM +0200, Josef Spillner wrote:
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.
*Schrei*: http://qa.debian.org/developer.php?login=twerner@debian.org - 10 Pakete mit RFA (request for adoption) und eins mit RFH (request for help). Ich richte gern auch alioth-Projekte ein und lade meine privaten SVNs dahin. Uploads übernehme ich gerne, wenn der neue Maintainer einen Sponsor braucht.
Anderes Beispiel: http://alioth.debian.org/projects/pkg-otrs/ , im November eingerichtet und bis heute nur ein Mitentwickler, der noch nichts beigetragen hat.
Theoretisieren hilft *nichts*, mitmachen ist wichtig und Debian bietet viele Möglichkeiten zum mitmachen, auch für Leute ohne Account auf debian.org. Josefs Punkten kann ich mich anschließen. Außerdem gibt es bereits 'make check', ich weiß aber nicht, wieviel Pakete das bereits nutzen.
Viele Grüße, Torsten
lug-dd@mailman.schlittermann.de
-
guettli -
Josef Spillner -
Konrad Rosenbaum -
Matthias Petermann -
Steffen Liebergeld -
Torsten Werner