sound-probz mit arts und oss

[Ronny Buchmann]

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