sound-probz mit arts und oss

[Michael Schwendt]

On Wed, 28 Jan 2004 23:47:57 +0100, Ronny Buchmann wrote:

> 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.

"Etwas" mehr ist aber notwendig, um Probleme entweder von vornherein zu
reduzieren oder sie nachher zu beheben. Ein altes src.rpm von z.B. Red Hat
Powertools zu nehmen, einen neuen source tarball einzufügen und vielleicht
noch ein paar configure Parameter oder Abhängigkeiten manuell anzupassen,
ist keine Leistung. Eine Leistung entsteht aus sowas erst, wenn dabei
Verbesserungen vorgenommen und Schnitzer gefunden werden, Red Hat's
Bugzilla System nach noch offenen Bug Reports für das Paket abgesucht wird
oder auch ein Abgleich mit Debian's Paket und eventuellen Fixes darin
gemacht wird.  (Konfigurations- und Integrationsleistung mal außenvor
gelassen)

> > 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.

Das meine ich nicht, sondern das Getöse, wenn eine Software in irgendeinem
Repository schon seit Monaten als Paket angeboten wird, Nutzer sich aber
erst für die neuen Pakete eines anderen Repositories interessieren und
dazu Fragen stellen.
 
[-snip-]

> 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)

Ein "Code-Audit" ist nicht gemeint. Und der vor wenigen Wochen
unterbreitete Vorschlag, so könnten Pakete das QA System "umgehen",
entbehrt jeder Grundlage, ist geradezu indiskutabel.

> fedora.us würde auch von den (bisherigen) Packagern benutzt werden, wenn der 
> QA Prozess angemessen wäre, (davon ist er IMO weit entfernt)

Wann wäre er angemessen?

(Haben nicht einige der "bisherigen Packager" verlauten lassen, daß
sie nichtmal ein offizielles Fedora Extras unterstützen wollen, sondern
ein "3rd party repository" bleiben wollen?)
 
> Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche gestellt 
> werden sollten als an die in Core.

Ist das der Fall?
Was speziell mißfällt Dir?

> > 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 ...

wiederholt != öfter

Ein rekursiver "grep Saou" auf den Inhalt von allspecs.tar.gz findet
gerademal 9 Pakete, die im Changelog mehrmals den Namen Matthias Saou
stehen haben. Beispiel:

  $ grep Wieers * -R
  stable/gonvert.spec:* Sat Jun 29 2003 Dag Wieers <dag at wieers.com> - 0.1.6-0
  stable/gonvert.spec:* Wed Feb 26 2003 Dag Wieers <dag at wieers.com> - 0.1.5-0
  stable/libglademm2.spec:* Sat Mar 29 2003 Dag Wieers <dag at wieers.com> - 2.0.1-0
  stable/libgnomemm2.spec:* Sat Mar 29 2003 Dag Wieers <dag at wieers.com> - 1.3.10-0
  testing/awstats.spec:- many thanks to Michael Schwendt and Dag Wieers.

;-P

Ich denke, eher wird mit bereits existierenden Paketen verglichen, ob der
eigene Ansatz wohl richtig ist. Daß ein Packager ein Paket von irgendwoher
nimmt und sich nicht mit dem spec Skript vertraut macht, kommt hoffentlich
_nicht_ öfter vor.

> > 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.

Wie sollte es bei einem manuellen Build System anders aussehen?  Dann
hätte das Build Team nichts anderes zu tun, als Pakete abzuweisen, die
vor, während oder nach der Compilierung kläglich scheitern, nichtmal
funktionieren, mit falschen Dateizugriffsrechten versehen sind oder so mit
manuell gesetzten Abhängigkeiten bestückt sind, daß es beim nächsten
Update Problem gibt.

Ein öffentliches Community Packaging Projekt verlagert zudem leider einen
Teil der Paketentwicklung in das QA System.

Anders sähe es aus, wenn der Packager ein automatisiertes Build System
verwenden könnte, das sicher gegen Einbruchversuche von außen und innen
ist. Aber selbst dann könnte er Pakete bauen, die mit gefährlichen oder
unsinnigen Abhängigkeiten ausgestattet sind und zu Problemen führen.

Etwas für "unstable" hab ich lang nichtmehr gesehen. Das sind gerademal
ein Dutzend Pakete drin. Das letzte Paket machte es am 30.November in
unstable. Das war Audacity 1.2.0 pre3, vermutlich auf Wunsch des
Packagers, crashte auch mit GTK2. Oder AIDE CVS Version mit Segfaults. Das
Final Release hat später jemand in "testing" haben wollen.

Kommen wir zu "testing", einem Sammelplatz für development Versionen oder
Pakete, die der Packager noch nicht über stable auf die Masse der Nutzer
loslassen möchte. Bei fedora.us trifft man auf einen Spruch ala "good
enough for testing", der besagt, daß jemand sich während der Reviewphase
um technische Details gekümmert hat, aber die Stabilität zur Laufzeit oder
Funktionsfähigkeit nicht großartig über mehr als einen einfachen
Startversuch hinaus untersucht hat.

Aber warum sollte das QA System für testing/unstable wegfallen? Damit
würde ja auch der MD5 Abgleich des Upstream Source und ein Blick in das
spec Skript oder Patches wegfallen. Unverantwortlich.

> 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)

rpmlint ist viel zu irreführend und unzuverlässig, selbst in angepaßter
Version für fedora.us.

Und was mit "QA" gemeint ist, ist eben nicht wohldefiniert. Ich sehe über
einige fragwürdige QA Empfehlungen lächelnd hinweg, weil ich mit Packagern
zusammenarbeite, anstatt ihnen unnötig das Leben schwer zu machen, wo in
meinen Augen kein Wertschöpfungspotential besteht.

--