[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Snapshots, Entwickler-Branchs, CVS-Auszüge, etc. in unstable



Dirk Prösdorf <d.proesdorf@gmx.de> wrote:
> mal die Frage, welchen Sinn es macht, dass Maintainer in unstable 
> Software-Versionen aus Entwickler-Linien einpflegen.

Hallo!
Es kann _sehr_ viel Sinn machen, nehmen wir eine Software, deren
stable-Zweig 1.2 seit zwei Jahren nicht mehr angefasst wurde, und wo
ein Release fier 1.4 im naechsten halben Jahr bevorsteht. Wenn man in
sid bei 1.2 bis zum Release von 1.4 bliebe, waere die Version
weitgehend ungetestet, und beim Wechsel der Debian Version auf 1.4
wuerden massig neu Fehler gefunden werden. Sehr unguenstig, wenn wir
eigentlich sarge rausbringen wollen, da ziehen wir das lieber ein
halbes Jahr vor, testen in sid, und haben ein 1.4-1, das
Releasequalitaeten hat.

> Wäre es nicht sinnvoller, wenn diese nach 'experimental' gehen würden?

Experimental testet kaum jemand, und es gibt keine Autobuilder dafuer.

> Gerade bei mutt, inn2 und tin fällt mir dies auf

Bei inn2 stand ein groesserer Sprung an (iirc 2.4) und der Maintainer
hat eben wie oben angedeutet zu Testzwecken frueher umgestellt, damit
nicht alles zu dem Zeitpunkt auseinanderfaellt, wenn man eine
getestete Version fuer sarge bei der Hand haben sollte.

> und bei tin wird es wohl (zumindest wie ich den
> unstable->testing->stable Prozess verstehe) nie eine Stable-Version
> nach Sarge schaffen.

Hat Marco schon eine 1.7er Version hochgeladen? (In woody ist vor
allem darum eine 1.5er Version, weil 1.4 non-free ist.)

Oft greift die Kennzeichnung "Entwickler-Linie" auch einfach zu kurz,
z.B. bei GNU software, tar und find hatten schon viele Jahre lang kein
"stable" Release, da kommt man gar nicht umhin, zu alpha.gnu.org zu
greifen. (Das machen alle andere grossen Distributionen ausser
Slackware auch.) Es ist sehr unterschiedlich, was die Softwareautoren
als "Entwickler-Linie" bezeichnen, die Versionsnummer sagt wenig
darueber aus, man muss die entsprechenden ML lesen.

Bei cdrecord ist es aehnlich, die stable Version wird nur angefasst,
wenn ein wirklich schwerer Fehler darin gefunden wird (so schwer, dass
er auch in Debian/stable gefixt wuerde), bei normalen Bugs bekommt man
von JS nur den Hinweis, die aktuelle alpha zu verwenden, er koenne
nicht zwei Version unterstuetzen.
                  cu andreas



Reply to: