Re: Snapshots, Entwickler-Branchs, CVS-Auszüge, etc. in unstable
Dirk Prösdorf [EMAIL PROTECTED] 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 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Snapshots, Entwickler-Branchs, CVS-Auszüge, etc. in unstable
Hi, Dirk Prösdorf wrote: mal die Frage, welchen Sinn es macht, dass Maintainer in unstable Software-Versionen aus Entwickler-Linien einpflegen. Warum nicht? Wäre es nicht sinnvoller, wenn diese nach 'experimental' gehen würden? Kommt drauf an. Gerade bei mutt, inn2 und tin fällt mir dies auf und bei tin wird es wohl mutt's CVS ist aber stabil... Ich benutze es hier tagtäglich... (zumindest wie ich den unstable-testing-stable Prozess verstehe) nie eine Stable-Version nach Sarge schaffen. und? wenn das CVS tin stabil läuft? Es wird nur (wie 99% in sid) wegen der libc zurückgehalten. Es kommt immer drauf an, wie der Maintainer die Version beurteilt. viewcvs ist ein abschreckendes Beispiel dafür, aber den Maintainer kennen wir ja schon :( aj hat vor kurzem geschrieben, das CVS snapshots, die nicht für stabil beutrteilt werden doch bitte nach experimental sollen, aber wenn diese stabil sind, warum sollten sie nicht nach unstable? Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: Snapshots, Entwickler-Branchs, CVS-Auszüge, etc. in unstable
Dirk Prösdorf [EMAIL PROTECTED] writes: Ja, hat er, aber jetzt hat er den 2.4.0 schon wieder raus genommen und ist wieder auf den aktuellen Snapshot übergegangen. Sprich, wenn ISC nicht in den nächsten Wochen inn 2.4.1 frei gibt, dann dürfte Sarge keinen stabilen inn2 haben. Finde ich etwas gewagt. das ist ein gutes zeichen fuer ein bevorstehendes release. [EMAIL PROTECTED] -- frobnicate foo -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Snapshots, Entwickler-Branchs, CVS-Auszüge, etc. in unstable
Dirk Prösdorf [EMAIL PROTECTED] wrote: Andreas Metzler [EMAIL PROTECTED] wrote: [...] Bei inn2 stand ein groesserer Sprung an (iirc 2.4) und der Maintainer hat eben wie oben angedeutet zu Testzwecken frueher umgestellt, Ja, hat er, aber jetzt hat er den 2.4.0 schon wieder raus genommen und ist wieder auf den aktuellen Snapshot übergegangen. Sprich, wenn ISC nicht in den nächsten Wochen inn 2.4.1 frei gibt, dann dürfte Sarge keinen stabilen inn2 haben. Finde ich etwas gewagt. Dazu kann ich nichts wertendes beisteuern, weil ich keine Ahnung ueber die Unterschiede 2.4.0 und die CVS-Version in Debian habe, ich kann nur erneut einwerfen, dass die Versaionsnummer sehr wenig sagt, es ist gut moeglich, dass der Unterschied nur 15 Bugfixes sind. [...] 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.) Ja, sonst würde ich es ja nicht schreiben. Ich persoenlich haette wohl 1.6.2 gewaehlt. Andereseits moechte ich zu bedenken geben, dass der Unterschied zwischen 1.6.2 und aktuellem 1.7 snapshot fast ausschlieslich in der Versionsnummer liegt, dh. es ist mehr ein kosmetisches Problem. 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. Was aber bei INN und tin nicht so ist. Korrekt. Gerade bei diesen beiden finde ich es eher eigenartig, wenn da nicht die Stable-Versions in Sarge laden würden. Ich weiss nicht. Die 1.5er Version von tin in woody ist so schlecht nicht, da war imho Marcos Wahl nicht ungluecklich, zu inn siehe oben. cu and- der ernsthaft in Erwaegung zieht einen findutils CVS snapshot hochzuladen, da da die grosse Release-Angst zu herrschen scheint. -dreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Snapshots, Entwickler-Branchs, CVS-Auszüge, etc. in unstable
On 15.Sep 2003 - 00:04:12, Dirk Prösdorf wrote: Moin, mal die Frage, welchen Sinn es macht, dass Maintainer in unstable Software-Versionen aus Entwickler-Linien einpflegen. Nun in unstable ist i.A. immer die neueste Software. Außerdem liegt das im Ermessen des Maintainers, wenn dieser eine CVS-Version ... für stabil genug hält und in seinem Paket gerne die neuesten Features anbieten möchte packt er die CVS-Version. Oft jedoch kommen zuerst parallel zum originalen Paket Versionen mit cvs im Namen,so z.B. bei galeon und irgendwann werden die beiden Varianten dann vereinigt. Wäre es nicht sinnvoller, wenn diese nach 'experimental' gehen würden? Gerade bei mutt, inn2 und tin fällt mir dies auf und bei tin wird es wohl (zumindest wie ich den unstable-testing-stable Prozess verstehe) nie eine Stable-Version nach Sarge schaffen. Also mutt 1.5.4 ist bereits in sarge. Ansonsten ist es manchmal auch so, das die jeweils stabilen Versionen nicht wirklich gut vom upstream gepflegt werden. Über den Sinn/Unsinn dieser Dinge musst du also mit den Maintainern streiten. Andreas -- Sich im Dreck zu wälzen, ist kein gutes Mittel, um sauber zu werden. -- Aldous Huxley -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
