On Wednesday 28 January 2004 15:15, Michael Schwendt wrote:
On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote:
> Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum die
> Vermutung der "ideologischen" (vielleicht etwas irre leitender Ausdruck)
> Nähe.
*Dort* habe ich die Möglichkeit mitzuwirken. Bei freshrpms wäre ich
abhängig von mail > /dev/null Symptomen und der Lust und Laune einer
Einzelperson, etwas mehr Zeit für ein Paket zu opfern, als notwendig war,
um einfach nur die neueste Version "herauszuhauen".
"etwas mehr
Zeit"? Gegen "etwas" hat kaum jemand etwas, von "etwas" kann aber
keine Rede sein.
Der Eindruck der Lagerbildung verhärtet sich, wenn mit
Formulierungen, wie
z.B. "authoritative packager", mächtig auf die virtuelle Buschtrommel
geklopft wird.
Wenn du damit
http://dag.wieers.com/home-made/apt/mega-merge.php
meinst:
das ist ein simpler Abstimmungsmechanismus zwischen den 4 großen Repositories,
nicht mehr und nicht weniger.
> > Darum geht es gar nicht. Ich bevorzuge halt das Modell
eines offenen,
> > von der Community betreuten Repositories gegenüber dem [bis auf eine
> > Mailing Liste] geschlossenen Modell eines Repositories einer
> > Einzelperson.
>
> Ganz meine Meinung. Das Stichwort Bugzilla hast du ja schon ganz zu
> Recht genannt. Allerdings sehe ich die Fedora Community noch nicht
> entsprechend stark, um die Leistungen der bisherigen Einzelleistungen
> insgesamt auffangen zu können.
Der Schein trügt insofern, als daß die "Einzelleistungen" ungleich
verteilt sind. Zu jedem geschnürten und öffentlich angebotenen Paket
gehört ein Stück Verantwortung, für dieses Paket ggf. auch [Security]
Fixes bereitzustellen, die Software auf Schwachstellen zu untersuchen
(etwa bei Daemons oder Software, die als Superuser ausgeführt wird), neue
Das ist
zwar theoretisch richtig, aber in der fedora.us QAChecklist steht
nichts von einem Code-Audit (ich halte es auch für praktisch kaum machbar)
Versionen auf veränderte Anforderungen im Paketbereich zu prüfen
oder
Upgrades auf Regression zu testen. Auf solche Leistungen wird auf Seiten
der Individuen, die große Repositories im Alleingang verwalten, garnicht
erst eingegangen. Da fragt keiner, wie es möglich ist, daß ein Packager
noch am gleichen Tag ein neues Release in RPM Form anbietet oder sogar
Pakete in der Core Distribution ersetzt. Und wenn einmal Nutzer nach einem
Update drängen, taucht der Packager ggf. für einige Zeit unter. Es besteht
ich habe
noch keinen "untertauchen" sehen
ja keine Verpflichtung gegenüber den Nutzern. Nun finde aber mal
jemanden,
der guten Gewissens ein paar Hundert Pakete im Alleingang verwalten möchte
und im Urlaub nicht fürchtet, daß (Beispiel Gaim) sich in den Paketen
grausige Bugs auftun. Hier klafft eine Lücke zwischen denjenigen, die ohne
Gewissensbisse einfach Pakete anbieten und denjenigen, die eher auf
Arbeitsteilung hoffen und auf ein Community Project setzen, wo hoffentlich
andere einspringen, wenn man selbst verhindert ist. In der öffentlichen
fedora.us
würde auch von den (bisherigen) Packagern benutzt werden, wenn der
QA Prozess angemessen wäre, (davon ist er IMO weit entfernt)
Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche gestellt
werden sollten als an die in Core.
http://fedora.us/QA queue ist es zum einen wiederholt vorgekommen,
daß
Pakete von anderen Repositories erst nach mehreren Korrekturen sauber und
mit vorhersagbarer Konfiguration compilierten. Ebenso ist es schon öfter
vorgekommen, daß ein Update während der Review-Phase nicht für gut genug
befunden wurde, weil z.B. ärgerliche Bugs gefunden wurden. Dann zu sehen,
wie die gleiche Software inklusiver gleicher Bugs (oder vielleicht sogar
Es kommt
wohl öfter vor, das Pakete 1:1 übernommen werden ...
noch Paketfehlern) in einem Repository einer Einzelperson auftaucht,
das
schmälert die Einzelleistung ungemein. Und zu sehen, wie ein Paket lange
in der Warteschlange hängt, weil niemand, der es _nach_ Veröffentlichung
aber sofort installieren würde, den Mut hat, es nach einem Test
abzusegnen, ist schon erbärmlich.
Eine QA-Warteschlange für unstable/testing zu
haben ist einfach nur krank.
Da ist ja Debian noch human dagegen. Warum gibt es nicht einfach ein "qa" und
ein "stable" Repository? (Als Eintrittschwelle für qa sollte rpmlint +
Buildsystem reichen)
--
http://LinuxWiki.org/RonnyBuchmann