Der neue projektleiter will dann wohl debian 11 in debian 2021 umbenennen. Das ist heutzutage so usus und Versionsnummern als Jahreszahlen setzen sich durch.
Denn es ist viel einfacher eine Distri, die die Jahreszahl in der Versionsnummer hat, zeitlich einzuordnen, als das bei einer Distri der Fall wäre, die das nicht hat.
Ohne nachzugucken: Wann erschien Ubuntu 6.04 und wann erschien Debian 1.3? Das Jahr des Erscheinens von Ubuntu 6.04 kann ich dir sofort sagen.
Im übrigen kann man auch so viel besser abschätzen, wie lange der Support noch laufen dürfte, ohne jetzt nachschauen zu müssen.
Eine Versionsnummer nach Jahreszahl ist somit bei Distributionsversionen in jeder Hinsicht besser.
Lediglich bei Programmversionen und Libs sieht es anders aus, da will ich nämlich wissen, welche Minorversion noch zu einer Majorversion gehört. Mit Jahreszahlen als Versionsnummer wäre so etwas schlecht umsetzbar.
Von kamome umidori am Di, 19. März 2019 um 21:10 #
> Wann erschien Ubuntu 6.04 und wann erschien Debian 1.3?
Schlecht gewähltes Beispiel, oder? Halten wir zunächst fest: Debian 1.3 gibt es … ;) Sonst stimme ich dem ersten Teil zu. Aber Programme und Bibliotheken kann man doch ruhig mit Jahreszahlen benennen – eben nur die Major-Versionen, eine 2019-r3.2 kann dann ja ruhig irgenwann veröffentlicht werden (z.B. 2020).
Wenn du im nächsten Jahr eine Minorversion von der Lib raushauen will, wie soll die dann heißen?
2020-r4 oder doch eher 2019-r4, weil diese ja auf der Majorversion 2019... basiert, wobei dann das r4 für die Minorversion steht?
Noch eine kleine Ergänzung:
Und dann muss man ja noch an die ganzen autobuildscripte denken.
Mit einer klassischen Versionsnummer ist es einfach, da kann man sagen:
Pseudocode:
"baue nur, wenn die Majorversion = 2.x ist, ansonsten melde einen Fehler oder tue dies."
Wie macht man das mit Jahreszahlen?
"baue nur, wenn die Majorversion = 2019 ist, ansonsten ..."
Ups, jetzt haben wir ja die Minorversion vergessen. Also nochmal: "baue nur, wenn die Majorversion = 2019 oder 2020 ist".
Ja, jetzt ist es blöd, denn auch wenn wir hier die gleiche Majorversion haben, kommt im Herbst ja die neue Majorversion. Also nochmal: "baue nur, wenn die Majorversion = 2019 ist oder 2020 lautet, wobei die nicht Minorversion, dann nicht mit r1 anfangen darf. (Anmerkung: die nächste Major fängt ja wieder bei r1 für die Minorversion an zu zählen.
Oder es kommt im Herbst keine Majorversion raus und wir wollen ein Zukunftsicheres Buildscript. Bis in welches Jahr sollen wir dann testen bwz. in die Glaskugel schauen, um zu sehen, dass sich die Majorversion wirklich ändert?
"baue nur, wenn die Majorversion = 2019 ist, oder 2020 oder 2021 oder..."
Allenfalls müsste man das so machen, dass die Majorversion das Jahr beibehält, auch für die späteren Minorversionen der nächsten Jahre. Aber was macht man, wenn im gleichen Jahr zwei Majorversionen rauskommen?
Bei Distris ist das nicht so schlimm, denn da wird die zweite Version im Jahr einfach mit der Monatszahl angegeben und Korrekturen bekommen fortlaufende Nummern.
Von kamome umidori am Mi, 20. März 2019 um 22:30 #
> Warum ist das Beispiel schlecht gewählt? > Klar gab es Debian 1.3.
Ja, Ubuntu 6.04 aber nicht!
> Wenn du im nächsten Jahr eine Minorversion von der Lib raushauen will, wie soll die dann heißen?
2019-r4 Das funktioniert genauso gut wie jedes andere x.4 – nur hast Du die Zusatzinformation, in welchem Jahr die Version ursprünglich veröffentlicht wurde (also die x.0).
Meines Wissens wurde/(wird?) bei Debian jeweils eine neue Version veröffentlicht, wenn entschieden wurde, einen neuen (langzeitunterstützten) Kernel als Basis der Distribution zu nehmen.
Debian 11 wäre demnach das elfte Mal, dass ein neuer Kernel als Basis genommen wird.
Ich persönlich begrüsse es, dass die Nummerierung der Debian-Ausgaben beibehalten wird; egal ob sie mir gefällt oder nicht, sie ist in sich schlüssig und nachvollziehbar.
Das ist ähnlich wie bei Datumsbezeichnungen; je nach Land sind diese unterschiedlich, aber dort immer gleich, also zuordenbar. Genauso wie ich weiss, wie ich das Datum lesen muss, wenn ich in ein bestimmtes Land reise, weiss ich bei Debian, wie ich die Versionsnummer interpretieren muss. Und wenn ich mir nicht mehr sicher bin, kann ich in der Dokumentation von Debian nachlesen, wie die Zahlen ausgelegt werden müssen...
Es grüsst
Roland
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 20. Mär 2019 um 08:24.
Ich finde es prima, dass sich nun doch noch Kandidaten gefunden haben. Das ohnehin schon hierarchisch extrem flach aufgestellte Debian-Projekt mag ich mir ohne einen DPL gar nicht vorstellen.
Nicht, dass ich falsch verstanden werde: Debian als Projekt ist, was es ist. Und ich finde es immer wieder faszinierend, wie groß, weitreichend, vielfältig, offen und erfolgreich dieses Projekt ist. Mir fällt spontan kein anderes Projekt ein, welches diese Maßstäbe und Skalen erreicht hätte, und trotzdem weiterhin relativ rund läuft und gedeiht. In dem Sinne erscheint es mir als einzigartiges Projekt dieser Ausmaße und mit solch' anarchistischen/meritokratischen Strukturen. Natürlich schwingen bei Debian stark ausgeprägte ideologische Züge mit, die sich in der Verfassung, den darin definierten Prozessen und sicherlich auch den gründenden und teilnehmenden Personen niederschlagen. Das hat gleichzeitig Vor- & Nachteile.
Um einen Überblick über die Tätigkeiten der/des DPLzu erhalten, habe ich mir einige der "Bits from the DPL"-Mails des nun ex-DPLs Chris Lamb angeschaut. Ohne Chris Lamb oder dessen Taten für Debian selbst kritisieren zu wollen, möchte ich anmerken, dass die allermeisten Tätigkeiten, die dort aufgeführt werden, auf mich wirken, als würden sie eher ins Aufgabenfeld eines Sekretärs oder einer Arbeitskraft für Öffentlichkeitsarbeiten passen. Geht euch das ebenfalls so? [Randdiskussion: Wäre es diskriminierend, falls ich statt "eines Sekretärs" "einer Sekretärin" geschrieben hätte, oder falls ich es zusätzlich ergänzt hätte? Und gibt es eigentlich eine männliche oder (gender-)neutrale Form für das Wort "Arbeitskraft"? Fragen über Fragen...]
Dass es sinnvoll sein kann, dass ein Projektleiter Öffentlichkeitsarbeit leistet, falls keine andere Arbeitskraft hierfür zuständig ist, stelle ich nicht in Frage. Aber wie zielführend und effektiv ist ein solches Tätigkeitsfeld der Rolle eines Projektleiters für das Debian-Projekt in der Praxis? Wie kann man die Rolle für das Projekt effektiver auskleiden und gestalten?
Die Rolle des DPLs stelle ich mir einerseits sehr facettenreich, zeitraubend, und mitunter müßig vor, aber andererseits ist es eine Position, die nur mit schwach Kompetenzen ausgestattet ist und damit zahn- und machtlos ist, nicht honoriert wird, und generell eher Geringgeschätzung erfährt. Wer möchte sich soetwas freiwillig antun? Wer wird damit glücklich und erfüllt? Sind es unerfahrene, naive, oder ideologisch verbohrte Menschen, die sich darauf einlassen? Wie wirkt sich das auf das Projekt aus? Hat das Debian-Projekt zu wenig finanzielle Ressourcen, um eine halbe oder ganze Stelle des DPL auszuschreiben?
Obwohl ich mit Debian nichts Größeres am Hut habe, habe ich mir einmal die Zeit genommen, die "Wahlprogramme" (platforms) der DPL-Kandidaten zu überfliegen. Mich persönlich sprechen die "Bewerbungsschreiben" von Sam Hartman und Martin Michmayr am ehesten an. Sie scheinen die aktuelle Situation, in der sich Debian aus meiner Sicht befindet, am treffendsten analysiert zu haben. Auch wenn darin so Manches fast dystopisch klingen mag, denke ich, dass dies die einzig sinnvolle Grundlage für eine erfolgreiche Planung zukünftiger Aktivitäten darstellt. Denn wenn man etwas verbessern oder ändern möchte, muss man erst zentrale/ursächliche Probleme identifizieren und realisieren. Das mag zwar für alle Beteiligiten zunächst recht unangenehm sein, ist aber unausweichlich, falls die identifizierten "Fakten" der Realität entsprechen. Und die resultierenden technischen Probleme sind in erster Linie eigentlich fast immer sozialer oder kommunikativer Natur.
Bei all' den eskalierten öffentlichen Diskussionen, technischen Patzern und personellen Abgängen Debians, stellt sich mir die Frage, ob Debian möglicherweise "zu offen" ist, sodass es Gefahr läuft, sich langsam von innen aufzuweichen und zu zersetzen, um dann von außen zu verwittern. Es wäre nicht das erste "Projekt", welches dieses Schicksal ereilt. Von anderen Distributionsprojekten (FreeBSD, Fedora, openSUSE, Ubuntu, Mint, Manjaro, Arch, Mageia, Gentoo, Void Linux, NixOS) hört man in der Regel viel weniger. Woran liegt das? Wie handhaben die das? Haben die "bessere" Strukturen, Prozesse oder Hierarchien?
Meiner Meinung nach würden Debian ein schärferer Fokus, klarere & simplere Arbeitsablaufsmuster/-beitragsprozesse und eine rigorosere Trennung von Altlasten gut tun. Das Motto "The Universal Operating System" findet in der heutigen Zeit kaum Platz. "Und wer erledigt die nötige Arbeit?" ist natürlich eine berechtigte Frage als Entgegnung zu Vorschlägen in einer Meritokratie. Ich denke, dass man trotzdem noch seine Meinung äußern darf, ohne ein Experte mit Zeit für die vorgeschlagenen Änderungsarbeiten zu sein, solange sie gut gemeint sind und konstruktiv daher kommen.
-- Nun habe ich Mal wieder mehr dazu geschrieben, als mir eigentlich lieb ist.
Von Michael Stehmann am Mi, 20. März 2019 um 16:34 #
"Natürlich schwingen bei Debian stark ausgeprägte ideologische Züge mit, ..."
Ich würde diese Züge nicht ideologisch, sondern ethisch nennen. Und das ist wohl auch das "Erfolgsgeheimnis" von Debian. Die allermeisten Beitragenden sind überzeugt von dem, was sie tun, und handeln aus Überzeugung.
Zum Projektleiter: Dieser hat zwar nach der Verfassung des Projektes durchaus eine gewisse Machtfülle, aber eben auch eine ziemlich kurze Wahlperiode. Letztere verhindert recht wirksam Machtmissbrauch.
Solange alles einigermaßen läuft, entspricht sein Aufgabenbereich eher dem eines Bundespräsidenten, als einer Bundeskanzlerin.
Da das Projekt viele starke Persönlichkeiten hat, braucht es keinen "starken Führer", der den anderen permanent klarmacht, "wo es lang zu gehen hat", nicht einmal einen "wohlwollenden Diktator" und schon gar keinen auf "Lebenszeit".
Sicherlich ist es gut, die Verfassung und Führung des Projektes auch von außen zu kritisieren. Hierfür schafft ja auch die vom Projekt gewollte Transparenz die notwendigen Voraussetzungen. Allerdings stellt sich manches mit einer langjährigen Erfahrung aus der Binnensicht sicherlich auch anders dar.
Ich bin zwar kein Mitglied dieses Projektes, kenne aber einige Beitragende, bin mit ihnen in Kontakt und habe auch die Verfassung des Projektes ein wenig studiert.
"Natürlich schwingen bei Debian stark ausgeprägte ideologische Züge mit, ..."
Ich würde diese Züge nicht ideologisch, sondern ethisch nennen. Und das ist wohl auch das "Erfolgsgeheimnis" von Debian. Die allermeisten Beitragenden sind überzeugt von dem, was sie tun, und handeln aus Überzeugung.
Nenn es, wie du's magst. Für mich sind es zwei Seiten der selben Medaille.
Ich finde es jedenfalls fraglich, inwieweit das Debian-Projekt tatsächlich davon profitiert, bspw. Firmware, die nicht der DFSG entspricht, von den Standard-Installationsmedien bzw. aus main absichtlich zu entfernen. Diese ist teilweise für eine erfolgreiche Installation absolut erforderlich (z.B. WiFi). Die Absicht hinter jener Entscheidung und die damit vermittelte Botschaft wird jedem potentiellen Anwender spätestens beim Fehlschlagen der Installation klar, und ich weiß Debians Konsistenz und Vehemenz in dieser Argumentation für diesen Punkt wirklich zu schätzen.
Aber ich vermute, dass diese Herangehensweise dem Projekt insgesamt eher schadet, als sie ihm nützt. Die allermeisten anderen Distros - sogar die kommerziellen - schaffen es, die Firmware auf dem Wege des geringsten Widerstands zu verteilen, meistens unter der Formulierung einer Ausnahme der selbst auferlegten, allgemeinen Paketierungsrichtlinien.
Natürlich stellt Debian für genau dieses Problem Installationsmedien mit "unfreier" Firmware bereit - wohlgemerkt inoffiziell und gut versteckt. Das ist eine unnötige Hürde für eine möglichst breiten Einsatz Debians. Das Argument, dass jene potontiellen Anwender, die an diesem Problem bereits "scheitern", sowieso nicht in/um Debian erwünscht sind, zeugt von einem Elitarismus, der hier wirklich fehl am Platze ist. Sogar ein Herr Torvalds ist mit solchen unnötigen Verkomplifizierungen nicht glücklich [0]. Das heißt gleichzeitig aber nicht, dass er ein Verfechter "unfreier" Firmware wäre.
Hinzu kommt noch das Beharren auf Inkompatibilitäten zwischen DFSG und der 'invariant sections' der GFDL [1]. Stattdessen wird Dokumentation nach nonfree verbannt und kann standardmäßig nicht installiert werden. Der Status besteht bis heute. Jede andere ernstzunehmende Distro verhält sich hier pragmatisch und vernünftig, z.B. mittels Ausnahmeregelungen für die GFDL, wenn es sein muss.
Inkonsequenterweise kümmert sich Debian ein feuchten Furz in rechtlichen Fragen/Angelegenheiten, wenn es um die Paketierung patentierter Software geht. Das hat zwar für den gemeinen, häuslichen Hobbyanwender einen schönen Nebeneffekt des Vorhandenseins diverser Multimediacodecs im Binärformat, aber inkonsequenter geht es nun wirklich nicht.
Gleiches gilt für diverse Forks, z.B. von Mozillas Software, die über Jahre unnötige Spannungen im Ökosystem verursacht haben.
Wer möchte unter diesen Bedingungen gerne freiwillige Beiträge zu diesem Projekt leisten?
Es sind diese (vielen, kleinen) Details, die das Gesamtbild trüben. Vernunft und Pragmatismus seitens Debian kann ich hier bei Leibe nicht erkennen. Es werden Entscheidungen für Maßnahmen aufgrund einer Überzeugung, nicht der Vernunft, gefällt, die dem Projekt vermutlich eher schaden. Deshalb schwingt das Pendel bei Debian aus meiner Sicht eher in Richtung Ideologie ggü. einer Ethik. Ideologisch nenne ich Dinge dann, wenn ein fast "heiliger" Kodex zur Wahrung von Werten, die bei der Formulierung des Kodex teils unbeachtet geblieben sind, ohne Bereitschaft zum Kompromiss und ohne der Aufnahme von Ausnahmen strikt angewendet wird. Ein Kodex kann nicht alle Situationen abbilden und muss stetig angepasst und erweitert werden. Die Welt ist komplizierter und facettenreicher als Regeln, die in Stein gemeißelt wurden, und das macht sie auch so schön.
Da das Projekt viele starke Persönlichkeiten hat, braucht es keinen "starken Führer", der den anderen permanent klarmacht, "wo es lang zu gehen hat", nicht einmal einen "wohlwollenden Diktator" und schon gar keinen auf "Lebenszeit".
Das war auch nicht meine Absicht. Zwischen der jetzigen Rolle des DPL und einem "wohlwollenden Diktator" liegen Welten. Eventuell trifft man sich ja bei einem Fünftel in dem gesamten Spektrum dazwischen. Ein finanziell unterstützter DPL mit nahezu den selben Kompetenzen wie bisher (aber dann auch mit "Pflichten") wäre in meinen Augen jedenfalls ein Gewinn für Debian als Projekt.
Die Kompetenz des Delegierens beim DPL würde im Debian-Projekt auch gar nicht funktionieren, da die Beitragenden dem DPL zu nichts verpflichtet sind.
Schwätzen kann man viel, viel wichtiger ist aber die Frage, wer seine Versprechen auch halten kann.
Ich persönlich würde mir einen Debian Projektleiter wünschen, der zum einen etwas von der Thematik versteht, damit die richtigen Entscheidungen getroffen werden können, aber zum anderen wünsche ich mir auch jemanden, der etwas von Design und Usability versteht. Viele Entwickler haben so etwas in der Regel nicht drauf.
Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben.
Was den Fokus von Debian betrifft, so sollten sie an der Einsteigerfreudlichkeit arbeiten, denn was Debian dringend braucht ist eine größere Community. Vor allem auch von Leuten, die keine Softwareentwickler sind. Denn Softwareentwickler neigen dazu, die Software zu verbessern, wenn man aber eine gute Wiki und guten Einsteigersupport haben will, dann braucht man Leute, die diese Hürde nicht überwinden und sich deswegen mit der Pflege der Wiki und des Einsteigersupports begnügen. Das kann man gut an Ubuntu sehen. Die Wikis sind sehr gut gepflegt, der Einsteigersupport ist erstklassig, wo es mangelt ist an der Software. Die guten Entwickler gehen da halt eher zu Debian.
Die Backports sollte man in freiwillige Backports und offiziell unterstützte Backports aufteilen.
Letztere sollten dann bezüglich Sicherheitspatches genauso intensiv gepflegt werden, wie jedes andere Paket im normalen Repository von Debian stable.
Dadurch könnte man die Distri vor allem bezüglich Pakete, die besonders wichtig sind, aktueller halten. Angefangen beim Kernel.
Momentan ist es leider so, dass die Backports eine recht freiwillige Sache sind, eine Garantie auf Sicherheitspatches gibt es dort nicht und das ist ein großer Nachteil.
Von Michael Stehmann am Mi, 20. März 2019 um 16:49 #
"Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben."
Debian Maintainer paketieren vorhandene Software. Nur im geringen Umfang entwickeln sie Software selbst für den "Eigenbedarf". (Natürlich gibt es einige, die auch im "Upstream"-Projekt mitarbeiten.)
Zwar wäre es gut, sie würden optisch ansprechende und einfach zu bedienende Programme paketieren. Darauf haben sie als Debian Maintainer aber nur einen geringen Einfluss (z. B. bei der Wahl eines Default Themes).
Und die künstlerischen Fähigkeiten sind bei einem Maintainer, der Bibliotheken packt, wohl eher nicht relevant.
Debian Maintainer paketieren vorhandene Software. Nur im geringen Umfang entwickeln sie Software selbst für den "Eigenbedarf". (Natürlich gibt es einige, die auch im "Upstream"-Projekt mitarbeiten.)
Das meinte ich nicht.
Ich meinte damit bspw. den Installer und dass die Software so gepackt wird, dass sie Out of the box benutzbar ist. Also bspw. auch die Sprachpakete mitinstalliert werden, wenn schon die Sprache gewählt wurde. Was monentan nicht der Fall ist -> Usabilitymangel.
>Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben.
Bin zwar kein Debian-Maintainer, aber das hier würde ich abliefern:
Schwätzen kann man viel, viel wichtiger ist aber die Frage, wer seine Versprechen auch halten kann.
Nunka, auf irgendeiner transparenten Grundlage muss man seine Wahl schon treffen können. Sonst wäre Debian eine Art Sekte.
Ich persönlich würde mir einen Debian Projektleiter wünschen, der zum einen etwas von der Thematik versteht, damit die richtigen Entscheidungen getroffen werden können, aber zum anderen wünsche ich mir auch jemanden, der etwas von Design und Usability versteht. Viele Entwickler haben so etwas in der Regel nicht drauf.
Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben.
Das stelle ich mir sehr schwierig in der Umsetzung vor. Wer soll das bewerten? Die Wähler? Sind diese im Durchschnitt kompetenter? Oder ein ernannter DPL-Bewerter? Dann wäre man aber wieder am selben Ausgangspunkt. Und außerdem würde man hiermit die ohnehin schon relativ hohen Hürden unnötig vergrößern.
Das kann man gut an Ubuntu sehen. Die Wikis sind sehr gut gepflegt, der Einsteigersupport ist erstklassig, wo es mangelt ist an der Software. Die guten Entwickler gehen da halt eher zu Debian.
Ich bin mir nicht sicher, aber ich glaube, gelesen zu haben, dass die Ubuntu-Wikis mit der signifikanter Hilfe einiger Mitarbeiter Canonicals erstellt, gepflegt und moderiert wurden.
Der neue projektleiter will dann wohl debian 11 in debian 2021 umbenennen. Das ist heutzutage so usus und Versionsnummern als Jahreszahlen setzen sich durch.
Debian ist ja dafür allseits bekannt, sich stets nach dem Zeitgeist zu richten...
Demzufolge wird man seinem Prinzip wohl treu bleiben und Debian 11 dann Debian 2017 nennen.
Das würde auch eher dem Ursprungsjahr der ausgelieferten Software entsprechen.
Was ich für keinen Fehler halten würde.
Denn es ist viel einfacher eine Distri, die die Jahreszahl in der Versionsnummer hat, zeitlich einzuordnen, als das bei einer Distri der Fall wäre, die das nicht hat.
Ohne nachzugucken:
Wann erschien Ubuntu 6.04 und wann erschien Debian 1.3?
Das Jahr des Erscheinens von Ubuntu 6.04 kann ich dir sofort sagen.
Im übrigen kann man auch so viel besser abschätzen, wie lange der Support noch laufen dürfte, ohne jetzt nachschauen zu müssen.
Eine Versionsnummer nach Jahreszahl ist somit bei Distributionsversionen in jeder Hinsicht besser.
Lediglich bei Programmversionen und Libs sieht es anders aus, da will ich nämlich wissen, welche Minorversion noch zu einer Majorversion gehört.
Mit Jahreszahlen als Versionsnummer wäre so etwas schlecht umsetzbar.
> Wann erschien Ubuntu 6.04 und wann erschien Debian 1.3?
Schlecht gewähltes Beispiel, oder? Halten wir zunächst fest: Debian 1.3 gibt es … ;)
Sonst stimme ich dem ersten Teil zu.
Aber Programme und Bibliotheken kann man doch ruhig mit Jahreszahlen benennen – eben nur die Major-Versionen, eine 2019-r3.2 kann dann ja ruhig irgenwann veröffentlicht werden (z.B. 2020).
Warum ist das Beispiel schlecht gewählt?
Klar gab es Debian 1.3.
Wenn du im nächsten Jahr eine Minorversion von der Lib raushauen will, wie soll die dann heißen?
2020-r4 oder doch eher 2019-r4, weil diese ja auf der Majorversion 2019... basiert, wobei dann das r4 für die Minorversion steht?
Noch eine kleine Ergänzung:
Und dann muss man ja noch an die ganzen autobuildscripte denken.
Mit einer klassischen Versionsnummer ist es einfach, da kann man sagen:
Pseudocode:
"baue nur, wenn die Majorversion = 2.x ist, ansonsten melde einen Fehler oder tue dies."
Wie macht man das mit Jahreszahlen?
"baue nur, wenn die Majorversion = 2019 ist, ansonsten ..."
Ups, jetzt haben wir ja die Minorversion vergessen. Also nochmal:
"baue nur, wenn die Majorversion = 2019 oder 2020 ist".
Ja, jetzt ist es blöd, denn auch wenn wir hier die gleiche Majorversion haben, kommt im Herbst ja die neue Majorversion.
Also nochmal:
"baue nur, wenn die Majorversion = 2019 ist oder 2020 lautet, wobei die nicht Minorversion, dann nicht mit r1 anfangen darf. (Anmerkung: die nächste Major fängt ja wieder bei r1 für die Minorversion an zu zählen.
Oder es kommt im Herbst keine Majorversion raus und wir wollen ein Zukunftsicheres Buildscript.
Bis in welches Jahr sollen wir dann testen bwz. in die Glaskugel schauen, um zu sehen, dass sich die Majorversion wirklich ändert?
"baue nur, wenn die Majorversion = 2019 ist, oder 2020 oder 2021 oder..."
Allenfalls müsste man das so machen, dass die Majorversion das Jahr beibehält, auch für die späteren Minorversionen der nächsten Jahre.
Aber was macht man, wenn im gleichen Jahr zwei Majorversionen rauskommen?
Bei Distris ist das nicht so schlimm, denn da wird die zweite Version im Jahr einfach mit der Monatszahl angegeben und Korrekturen bekommen fortlaufende Nummern.
> Warum ist das Beispiel schlecht gewählt?
> Klar gab es Debian 1.3.
Ja, Ubuntu 6.04 aber nicht!
> Wenn du im nächsten Jahr eine Minorversion von der Lib raushauen will, wie soll die dann heißen?
2019-r4
Das funktioniert genauso gut wie jedes andere x.4 – nur hast Du die Zusatzinformation, in welchem Jahr die Version ursprünglich veröffentlicht wurde (also die x.0).
Ah okay. Da habe ich mich dann wohl geirrt. Aber dafür gab es eine 6.06.
Und wenn du im Jahr zwei Majorversionen raushaust, was dann?
2006.06-r1
2006.10-r1
Meines Wissens wurde/(wird?) bei Debian jeweils eine neue Version veröffentlicht, wenn entschieden wurde, einen neuen (langzeitunterstützten) Kernel als Basis der Distribution zu nehmen.
Debian 11 wäre demnach das elfte Mal, dass ein neuer Kernel als Basis genommen wird.
Ich persönlich begrüsse es, dass die Nummerierung der Debian-Ausgaben beibehalten wird; egal ob sie mir gefällt oder nicht, sie ist in sich schlüssig und nachvollziehbar.
Das ist ähnlich wie bei Datumsbezeichnungen; je nach Land sind diese unterschiedlich, aber dort immer gleich, also zuordenbar.
Genauso wie ich weiss, wie ich das Datum lesen muss, wenn ich in ein bestimmtes Land reise, weiss ich bei Debian, wie ich die Versionsnummer interpretieren muss. Und wenn ich mir nicht mehr sicher bin, kann ich in der Dokumentation von Debian nachlesen, wie die Zahlen ausgelegt werden müssen...
Es grüsst
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 20. Mär 2019 um 08:24.Roland
Ich finde es prima, dass sich nun doch noch Kandidaten gefunden haben. Das ohnehin schon hierarchisch extrem flach aufgestellte Debian-Projekt mag ich mir ohne einen DPL gar nicht vorstellen.
Nicht, dass ich falsch verstanden werde: Debian als Projekt ist, was es ist. Und ich finde es immer wieder faszinierend, wie groß, weitreichend, vielfältig, offen und erfolgreich dieses Projekt ist. Mir fällt spontan kein anderes Projekt ein, welches diese Maßstäbe und Skalen erreicht hätte, und trotzdem weiterhin relativ rund läuft und gedeiht. In dem Sinne erscheint es mir als einzigartiges Projekt dieser Ausmaße und mit solch' anarchistischen/meritokratischen Strukturen.
Natürlich schwingen bei Debian stark ausgeprägte ideologische Züge mit, die sich in der Verfassung, den darin definierten Prozessen und sicherlich auch den gründenden und teilnehmenden Personen niederschlagen. Das hat gleichzeitig Vor- & Nachteile.
Um einen Überblick über die Tätigkeiten der/des DPLzu erhalten, habe ich mir einige der "Bits from the DPL"-Mails des nun ex-DPLs Chris Lamb angeschaut.
Ohne Chris Lamb oder dessen Taten für Debian selbst kritisieren zu wollen, möchte ich anmerken, dass die allermeisten Tätigkeiten, die dort aufgeführt werden, auf mich wirken, als würden sie eher ins Aufgabenfeld eines Sekretärs oder einer Arbeitskraft für Öffentlichkeitsarbeiten passen.
Geht euch das ebenfalls so?
[Randdiskussion: Wäre es diskriminierend, falls ich statt "eines Sekretärs" "einer Sekretärin" geschrieben hätte, oder falls ich es zusätzlich ergänzt hätte? Und gibt es eigentlich eine männliche oder (gender-)neutrale Form für das Wort "Arbeitskraft"? Fragen über Fragen...]
Dass es sinnvoll sein kann, dass ein Projektleiter Öffentlichkeitsarbeit leistet, falls keine andere Arbeitskraft hierfür zuständig ist, stelle ich nicht in Frage.
Aber wie zielführend und effektiv ist ein solches Tätigkeitsfeld der Rolle eines Projektleiters für das Debian-Projekt in der Praxis? Wie kann man die Rolle für das Projekt effektiver auskleiden und gestalten?
Die Rolle des DPLs stelle ich mir einerseits sehr facettenreich, zeitraubend, und mitunter müßig vor, aber andererseits ist es eine Position, die nur mit schwach Kompetenzen ausgestattet ist und damit zahn- und machtlos ist, nicht honoriert wird, und generell eher Geringgeschätzung erfährt.
Wer möchte sich soetwas freiwillig antun? Wer wird damit glücklich und erfüllt? Sind es unerfahrene, naive, oder ideologisch verbohrte Menschen, die sich darauf einlassen? Wie wirkt sich das auf das Projekt aus? Hat das Debian-Projekt zu wenig finanzielle Ressourcen, um eine halbe oder ganze Stelle des DPL auszuschreiben?
Obwohl ich mit Debian nichts Größeres am Hut habe, habe ich mir einmal die Zeit genommen, die "Wahlprogramme" (platforms) der DPL-Kandidaten zu überfliegen.
Mich persönlich sprechen die "Bewerbungsschreiben" von Sam Hartman und Martin Michmayr am ehesten an. Sie scheinen die aktuelle Situation, in der sich Debian aus meiner Sicht befindet, am treffendsten analysiert zu haben. Auch wenn darin so Manches fast dystopisch klingen mag, denke ich, dass dies die einzig sinnvolle Grundlage für eine erfolgreiche Planung zukünftiger Aktivitäten darstellt. Denn wenn man etwas verbessern oder ändern möchte, muss man erst zentrale/ursächliche Probleme identifizieren und realisieren. Das mag zwar für alle Beteiligiten zunächst recht unangenehm sein, ist aber unausweichlich, falls die identifizierten "Fakten" der Realität entsprechen. Und die resultierenden technischen Probleme sind in erster Linie eigentlich fast immer sozialer oder kommunikativer Natur.
Bei all' den eskalierten öffentlichen Diskussionen, technischen Patzern und personellen Abgängen Debians, stellt sich mir die Frage, ob Debian möglicherweise "zu offen" ist, sodass es Gefahr läuft, sich langsam von innen aufzuweichen und zu zersetzen, um dann von außen zu verwittern. Es wäre nicht das erste "Projekt", welches dieses Schicksal ereilt.
Von anderen Distributionsprojekten (FreeBSD, Fedora, openSUSE, Ubuntu, Mint, Manjaro, Arch, Mageia, Gentoo, Void Linux, NixOS) hört man in der Regel viel weniger. Woran liegt das? Wie handhaben die das? Haben die "bessere" Strukturen, Prozesse oder Hierarchien?
Meiner Meinung nach würden Debian ein schärferer Fokus, klarere & simplere Arbeitsablaufsmuster/-beitragsprozesse und eine rigorosere Trennung von Altlasten gut tun. Das Motto "The Universal Operating System" findet in der heutigen Zeit kaum Platz.
"Und wer erledigt die nötige Arbeit?" ist natürlich eine berechtigte Frage als Entgegnung zu Vorschlägen in einer Meritokratie. Ich denke, dass man trotzdem noch seine Meinung äußern darf, ohne ein Experte mit Zeit für die vorgeschlagenen Änderungsarbeiten zu sein, solange sie gut gemeint sind und konstruktiv daher kommen.
--
Nun habe ich Mal wieder mehr dazu geschrieben, als mir eigentlich lieb ist.
"Natürlich schwingen bei Debian stark ausgeprägte ideologische Züge mit, ..."
Ich würde diese Züge nicht ideologisch, sondern ethisch nennen. Und das ist wohl auch das "Erfolgsgeheimnis" von Debian. Die allermeisten Beitragenden sind überzeugt von dem, was sie tun, und handeln aus Überzeugung.
Zum Projektleiter: Dieser hat zwar nach der Verfassung des Projektes durchaus eine gewisse Machtfülle, aber eben auch eine ziemlich kurze Wahlperiode. Letztere verhindert recht wirksam Machtmissbrauch.
Solange alles einigermaßen läuft, entspricht sein Aufgabenbereich eher dem eines Bundespräsidenten, als einer Bundeskanzlerin.
Da das Projekt viele starke Persönlichkeiten hat, braucht es keinen "starken Führer", der den anderen permanent klarmacht, "wo es lang zu gehen hat", nicht einmal einen "wohlwollenden Diktator" und schon gar keinen auf "Lebenszeit".
Sicherlich ist es gut, die Verfassung und Führung des Projektes auch von außen zu kritisieren. Hierfür schafft ja auch die vom Projekt gewollte Transparenz die notwendigen Voraussetzungen. Allerdings stellt sich manches mit einer langjährigen Erfahrung aus der Binnensicht sicherlich auch anders dar.
Ich bin zwar kein Mitglied dieses Projektes, kenne aber einige Beitragende, bin mit ihnen in Kontakt und habe auch die Verfassung des Projektes ein wenig studiert.
Ich finde es jedenfalls fraglich, inwieweit das Debian-Projekt tatsächlich davon profitiert, bspw. Firmware, die nicht der DFSG entspricht, von den Standard-Installationsmedien bzw. aus
main
absichtlich zu entfernen. Diese ist teilweise für eine erfolgreiche Installation absolut erforderlich (z.B. WiFi).Die Absicht hinter jener Entscheidung und die damit vermittelte Botschaft wird jedem potentiellen Anwender spätestens beim Fehlschlagen der Installation klar, und ich weiß Debians Konsistenz und Vehemenz in dieser Argumentation für diesen Punkt wirklich zu schätzen.
Aber ich vermute, dass diese Herangehensweise dem Projekt insgesamt eher schadet, als sie ihm nützt. Die allermeisten anderen Distros - sogar die kommerziellen - schaffen es, die Firmware auf dem Wege des geringsten Widerstands zu verteilen, meistens unter der Formulierung einer Ausnahme der selbst auferlegten, allgemeinen Paketierungsrichtlinien.
Natürlich stellt Debian für genau dieses Problem Installationsmedien mit "unfreier" Firmware bereit - wohlgemerkt inoffiziell und gut versteckt. Das ist eine unnötige Hürde für eine möglichst breiten Einsatz Debians. Das Argument, dass jene potontiellen Anwender, die an diesem Problem bereits "scheitern", sowieso nicht in/um Debian erwünscht sind, zeugt von einem Elitarismus, der hier wirklich fehl am Platze ist. Sogar ein Herr Torvalds ist mit solchen unnötigen Verkomplifizierungen nicht glücklich [0]. Das heißt gleichzeitig aber nicht, dass er ein Verfechter "unfreier" Firmware wäre.
Hinzu kommt noch das Beharren auf Inkompatibilitäten zwischen DFSG und der 'invariant sections' der GFDL [1]. Stattdessen wird Dokumentation nach
nonfree
verbannt und kann standardmäßig nicht installiert werden. Der Status besteht bis heute.Jede andere ernstzunehmende Distro verhält sich hier pragmatisch und vernünftig, z.B. mittels Ausnahmeregelungen für die GFDL, wenn es sein muss.
Inkonsequenterweise kümmert sich Debian ein feuchten Furz in rechtlichen Fragen/Angelegenheiten, wenn es um die Paketierung patentierter Software geht. Das hat zwar für den gemeinen, häuslichen Hobbyanwender einen schönen Nebeneffekt des Vorhandenseins diverser Multimediacodecs im Binärformat, aber inkonsequenter geht es nun wirklich nicht.
Gleiches gilt für diverse Forks, z.B. von Mozillas Software, die über Jahre unnötige Spannungen im Ökosystem verursacht haben.
Wer möchte unter diesen Bedingungen gerne freiwillige Beiträge zu diesem Projekt leisten?
Es sind diese (vielen, kleinen) Details, die das Gesamtbild trüben. Vernunft und Pragmatismus seitens Debian kann ich hier bei Leibe nicht erkennen. Es werden Entscheidungen für Maßnahmen aufgrund einer Überzeugung, nicht der Vernunft, gefällt, die dem Projekt vermutlich eher schaden.
Das war auch nicht meine Absicht. Zwischen der jetzigen Rolle des DPL und einem "wohlwollenden Diktator" liegen Welten. Eventuell trifft man sich ja bei einem Fünftel in dem gesamten Spektrum dazwischen. Ein finanziell unterstützter DPL mit nahezu den selben Kompetenzen wie bisher (aber dann auch mit "Pflichten") wäre in meinen Augen jedenfalls ein Gewinn für Debian als Projekt.Deshalb schwingt das Pendel bei Debian aus meiner Sicht eher in Richtung Ideologie ggü. einer Ethik.
Ideologisch nenne ich Dinge dann, wenn ein fast "heiliger" Kodex zur Wahrung von Werten, die bei der Formulierung des Kodex teils unbeachtet geblieben sind, ohne Bereitschaft zum Kompromiss und ohne der Aufnahme von Ausnahmen strikt angewendet wird.
Ein Kodex kann nicht alle Situationen abbilden und muss stetig angepasst und erweitert werden. Die Welt ist komplizierter und facettenreicher als Regeln, die in Stein gemeißelt wurden, und das macht sie auch so schön.
Die Kompetenz des Delegierens beim DPL würde im Debian-Projekt auch gar nicht funktionieren, da die Beitragenden dem DPL zu nichts verpflichtet sind.
Ein Dankeschön für den Austausch deiner Ansichten
--
[0] DebConf14 QA with Linus Torvalds
[1] GFDL - invariant sections
"Wer möchte unter diesen Bedingungen gerne freiwillige Beiträge zu diesem Projekt leisten?"
Derzeit etwa tausend Menschen.
Die interessantere Frage wäre:
Wie viel Prozent aller Linux Benutzer möchten unter diesen Bedingungen Debian als Hauptsystem auf ihrem Desktoprechner benutzen?
Das ist korrekt. Es ging bei dieser Frage eher darum, ob und wie sich unnötige Reibereien zukünftig vorbeugen & verhindern lassen.
Schwätzen kann man viel, viel wichtiger ist aber die Frage, wer seine Versprechen auch halten kann.
Ich persönlich würde mir einen Debian Projektleiter wünschen, der zum einen etwas von der Thematik versteht, damit die richtigen Entscheidungen getroffen werden können, aber zum anderen wünsche ich mir auch jemanden, der etwas von Design und Usability versteht.
Viele Entwickler haben so etwas in der Regel nicht drauf.
Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben.
Was den Fokus von Debian betrifft, so sollten sie an der Einsteigerfreudlichkeit arbeiten, denn was Debian dringend braucht ist eine größere Community.
Vor allem auch von Leuten, die keine Softwareentwickler sind. Denn Softwareentwickler neigen dazu, die Software zu verbessern, wenn man aber eine gute Wiki und guten Einsteigersupport haben will, dann braucht man Leute, die diese Hürde nicht überwinden und sich deswegen mit der Pflege der Wiki und des Einsteigersupports begnügen.
Das kann man gut an Ubuntu sehen. Die Wikis sind sehr gut gepflegt, der Einsteigersupport ist erstklassig, wo es mangelt ist an der Software. Die guten Entwickler gehen da halt eher zu Debian.
Ergänzung:
Und was ich mir auch noch wünsche.
Die Backports sollte man in freiwillige Backports und offiziell unterstützte Backports aufteilen.
Letztere sollten dann bezüglich Sicherheitspatches genauso intensiv gepflegt werden, wie jedes andere Paket im normalen Repository von Debian stable.
Dadurch könnte man die Distri vor allem bezüglich Pakete, die besonders wichtig sind, aktueller halten.
Angefangen beim Kernel.
Momentan ist es leider so, dass die Backports eine recht freiwillige Sache sind, eine Garantie auf Sicherheitspatches gibt es dort nicht und das ist ein großer Nachteil.
"Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben."
Debian Maintainer paketieren vorhandene Software. Nur im geringen Umfang entwickeln sie Software selbst für den "Eigenbedarf". (Natürlich gibt es einige, die auch im "Upstream"-Projekt mitarbeiten.)
Zwar wäre es gut, sie würden optisch ansprechende und einfach zu bedienende Programme paketieren. Darauf haben sie als Debian Maintainer aber nur einen geringen Einfluss (z. B. bei der Wahl eines Default Themes).
Und die künstlerischen Fähigkeiten sind bei einem Maintainer, der Bibliotheken packt, wohl eher nicht relevant.
Ich meinte damit bspw. den Installer und dass die Software so gepackt wird, dass sie Out of the box benutzbar ist.
Also bspw. auch die Sprachpakete mitinstalliert werden, wenn schon die Sprache gewählt wurde. Was monentan nicht der Fall ist -> Usabilitymangel.
>Insofern wäre es schön, wenn jeder Debian Maintainer mal ein Bild malen würde, damit man sehen kann, ob sie ein Gespür für gutes Design und Usability haben.
Bin zwar kein Debian-Maintainer, aber das hier würde ich abliefern:
. .
o
_
Inspiriert vom User-Icon von KDE-Breeze!
Danke für den Austausch deiner Ansichten.
Nunka, auf irgendeiner transparenten Grundlage muss man seine Wahl schon treffen können. Sonst wäre Debian eine Art Sekte. Das stelle ich mir sehr schwierig in der Umsetzung vor. Wer soll das bewerten? Die Wähler? Sind diese im Durchschnitt kompetenter? Oder ein ernannter DPL-Bewerter? Dann wäre man aber wieder am selben Ausgangspunkt.Und außerdem würde man hiermit die ohnehin schon relativ hohen Hürden unnötig vergrößern. Ich bin mir nicht sicher, aber ich glaube, gelesen zu haben, dass die Ubuntu-Wikis mit der signifikanter Hilfe einiger Mitarbeiter Canonicals erstellt, gepflegt und moderiert wurden.
Nicht die deutschsprachigen, wie bspw. auf ubuntuusers.de