Ich denke der Ansatz von Debian ist heute einfach nicht mehr zeitgemäß. Die Software ist schon bei der Veröffentlichung steinalt und dementsprechend ist auch die Sicherheit nicht mehr gewährleistet. Zumindest für Desktopanwendungen sollte es ein Umdenken geben und hier die jeweils aktuelle Version ausgeliefert werden, damit man sicher über die Releaselebensdauer kommt. Auf dem Papier mag es zwar nett klingen, den Stand einzufrieren und nur noch Sicherheitslecks zu schließen, in der Praxis sieht es dann aber doch anders aus. Das fängt schon damit an, dass ich mich darauf verlassen muss, dass die Entwickler alle geschlossenen Lücken sauber dokumentieren und sich diese Änderungen immer zurück auf die steinalte Version portieren lassen. Zudem werden ja nicht nur Sicherheitslücken gestopft, sondern auch andere Programmfehler behoben. Als Nutzer sehe ich diese Verbesserungen aber fühestens beim nächsten Hauptrelease. Man kann es drehen und wenden wie man will, auf dem Desktop würde ich ein Debian nicht einsetzen, da die Software nicht sicher ist.
Ich denke der Ansatz von Debian ist heute einfach nicht mehr zeitgemäß.
Ich denke Stabilität kommt bei Systembetreuern nie aus der Mode. Neue Versionen bedeuten oft auch Konfigurationsänderungen oder das irgendwelche Abhängigkeiten kaputt gehen. Wenn einem das System mit jedem Update um die Ohren fliegt dann macht man irgendwann keine Updates mehr.
Die Software ist schon bei der Veröffentlichung steinalt und dementsprechend ist auch die Sicherheit nicht mehr gewährleistet.
So alt ist sie nun auch wieder nicht. Bis kurz vor dem Freeze werden noch neue Versionen eingepflegt. Danach werden aber sicherheitsrelevante Patches zurück portiert. Entsprechend ist diese "alte" Software genau so sicher wie aktuelle Software. Teilweise sogar sicherer. Ich denke da an sowas wie Heartbleed. Die OpenSSL Version die in Debian 6 vorhanden ist war überhaupt nicht anfällig für das Problem. Nur die neuere OpenSSL von Debian 7 musste dann mit einem Sicherheitpatch gefixt werden. Es ist überhaupt nicht selten das neue Funktionen auch neue Fehler enthalten.
Zumindest für Desktopanwendungen sollte es ein Umdenken geben und hier die jeweils aktuelle Version ausgeliefert werden, damit man sicher über die Releaselebensdauer kommt.
Wenn du die Debconf 17 verfolgt hast dürfte dir das Thema Flatpak aufgefallen sein. Das wäre ein Ansatz um eine Mischung aus stabiler Basis und neuem Desktop zu bekommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Aug 2017 um 12:13.
Ich denke Stabilität kommt bei Systembetreuern nie aus der Mode. Neue Versionen bedeuten oft auch Konfigurationsänderungen oder das irgendwelche Abhängigkeiten kaputt gehen. Wenn einem das System mit jedem Update um die Ohren fliegt dann macht man irgendwann keine Updates mehr.
Hier ist schon der erste Trugschluss. Mit Stabilität hat das ganze nicht zu tun, denn dann müsste man auch Bugfixes einspielen, was nicht passiert. Zudem sprach ich explizit vom Desktop, denn den liefert Debian ja auch mit aus.
So alt ist sie nun auch wieder nicht. Bis kurz vor dem Freeze werden noch neue Versionen eingepflegt. Danach werden aber sicherheitsrelevante Patches zurück portiert. Entsprechend ist diese "alte" Software genau so sicher wie aktuelle Software. Teilweise sogar sicherer. Ich denke da an sowas wie Heartbleed. Die OpenSSL Version die in Debian 6 vorhanden ist war überhaupt nicht anfällig für das Problem. Nur die neuere OpenSSL von Debian 7 musste dann mit einem Sicherheitpatch gefixt werden. Es ist überhaupt nicht selten das neue Funktionen auch neue Fehler enthalten.
Doch sie ist alt, teilweise sogar sehr alt um nicht zu sagen antik. Vom Freeze bis zur finalen Veröffentlichung vergeht bei Debian aber viel Zeit, da erscheint schon noch die ein oder andere neue Browserversion. Ich halte die alte gepatchte Software zudem nicht für sicherer aus den im ersten Post von mir genannten Gründen. Firefox ist hier das Paradebeispiel wie man es nicht machen sollte.
Meiner Meinung nach sollte man soweit wie möglich auf ESR-Versionen setzen und dann die Fixes auch aus dem Hauptzweig einspielen. Genauso wie man bei anderen Desktopanwendungen zumindest die Minorversionen als Updates bereitstellen sollte. Dort ändern sich auch keine Configs, was im Desktopbereich ohnehin keine große Rolle spielt.
Diese ganzen Containerformate halte ich ebenfalls für kritisch, da sie an der Idee der geteilten Bibliotheken vorbei geht und dann überhaupt niemand mehr weiß in welchem Paket nun anfällige Versionen irgendwelcher Bibliotheken verpackt sind. Dann lieber an zentraler Stelle für alle Anwendungen patchen.
Hier ist schon der erste Trugschluss. Mit Stabilität hat das ganze nicht zu tun, denn dann müsste man auch Bugfixes einspielen, was nicht passiert.
Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Zudem sprach ich explizit vom Desktop, denn den liefert Debian ja auch mit aus.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Zudem gibt es mit Debian Testing auch die Möglichkeit von etwas das man mit einem Rolling Release vergleichen kann. Sofern kein Freeze vorhanden ist fließen ständig Updates mit neuen Versionen in den Testing Zweig.
Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Es sit aber extrem nervig, wenn die mitgelieferte Version Bugs hat und die nicht behoben werden. Es wird zudem bei den meisten Programmen zwischen Bugfixversionen und denen die neue Funktionen bringen unterschieden. man kann sich ja mal die Versionsstände von Debian 8 anschauen kurz bevor 9 erschien. Da ist schon sehr altes Zeug dabei.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Sicher hat das seine Vorteil aber auch sehr viele Nachteile. Letztlich musst du darauf vertrauen, dass der Maintainer alle kritischen Lücken akribisch nachpflegt und selbst, wenn er das täte, ist er immer noch davon abhängig, dass auch der Entwickler alle geschlossenen Lücken sauber dokumentiert. Gerade letzteres passiert aber nicht immer. Zum einen, weil vielleicht gar nicht direkt klar ist, dass der behobene Bug auch als Sicherheitslücke missbraucht werden kann (siehe Debian und die längst gefixte Imagemagick-Lücke) oder weil der Entwickler Angreifer nicht zusätzlich darauf Aufmerksam machen will oder was weiß ich. Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Könnte daran liegen, dass Bugfix-Releases idR ohnehin 1:1 durchgereicht werden. Du glaubst doch nicht ernsthaft, dass sich ein Maintainer diese heiden Arbeit mit Backports macht wenn es nicht zwingend erforderlich ist. Backports werden nur dann gemacht wenn der Entwickler mal wieder seine 5 Minuten hatte und eine eindeutige Verhaltensänderung als Bugfix umdeklarieren wollte oder ein Versionsstrang sein EOL durch den Entwickler erreicht.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Sehr einfach. Man kann sich bei tausenden Paketen nicht darauf verlassen das nicht doch irgendwo in dem Minor Bugfix nicht doch irgendwas verändert wurde über das man dann stolpert.
Das klassische Versionsschema war immer Major.Minor.Patchlevel. Dabei sollten sowohl bei Patchlevel als auch Minor keine Inkompatiblen Änderungen enthalten.
Aber wie ich aus Erfahrung mit PHP Versionen weiß stimmt das nicht immer. Der Sprung von PHP 5.3 auf 5.4 war einer der extremsten die ich je gesehen habe, obwohl es nur ein "Minor" Sprung lt. Versionnummer war. Eine Menge Skript mussten angepasst werden da nichts mehr funktionierte. Bei PHP gab es auch Änderungen die nur als Bugfix Releases veröffentlicht wurden aber trotzdem dafür gesorgt haben das bestimmte Skript nicht mehr funktioniert haben.
Allerdings scheinen die Paketmaintainer von PHP auch schon langsam die Nase voll zu haben davon das die Entwickler Sicherheitspatches und andere Bugfixes nicht sauber trennen können. Daher werden die Patchlevel Releases bei PHP direkt durchgereicht.
Und auch bei einiger anderer Software werden Versionsänderungen durchgereicht da der Aufwand zu groß ist alles nach Sicherheitspatches zu durchleuchten.
Na, was heißt bei Debian schon pflegen? Eben nicht. Bei Debian werden keine Updates eingepflegt. Nur Sicherheitsaktualisierungen, aber die interessieren mich nicht. Nicht, dass ich den dafür nötigen erheblichen Aufwand geringschätzen würde.
Aber ein sicheres System sehe ich als Voraussetzung an. Unter Updates verstehe ich neue Funktionalität, Fehlerbehebung, verbesserte Übersetzung..... Wenn man "abgekündigte" Projekte weiter pflegen möchte, so sollte man das upstream oder in einem Fork machen.
Ich denke das einige komplett vergessen das Debian ein Projekt ist, welches komplett zum überwiegenden Teil von Freiwilligen gestemmt wird. Und Arbeit an Paketen passiert nicht von selbst sondern von echten Menschen. Ich kenne keinen Maintainer der abgeneigt wäre wenn andere, nicht direkt im Debian Projekt involvierte Beitragende Hilfe, in welcher Form auch immer, anbieten. Es ist ebenfalls auch relativ einfach selber ein Paket zu pflegen, dazu hat Debian vor einigen Jahren schon den Status eines 'Debian Maintainers' eingeführt. Infos zu den verschiedenen Nomenklaturen der Beitragenden unter https://wiki.debian.org/Maintainers
Viele Beschwerden kommen immer wieder von Personen mit der Begründung Debian hätte nur [*]alte Software. Und das mag partiell stimmen, aber pauschal gesprochen trifft dies einfach nicht zu. Wer meint Software xy ist zu alt kann, nein der sollte sich gerne an den jeweiligen Maintainer oder auch die diversen ML wenden. Es kommt auch vor das Maintainer sogenannt MIA (Missing in Action) sind, sprich aktuell nicht erreichbar. Dies kann dann verschiedene Gründe haben, jedoch kann niemand der im Projekt tätig ist zu etwas gezwungen werden wenn er dies nicht will.
Zur Klärung von Meinungsverschiedenheiten unter den Entwicklern gibt es das TC (Technical Commitee). An dieses kann sich gewendet werden wenn alle andern Optionen einer Lösungsfindung versagt haben. Siehe https://www.debian.org/devel/tech-ctte
Kurzum, wenn jemand ein Problem mit einem Paket hat dann bitte eine Fehlermeldung (Bugreport) absenden! Wenn der Paktemaintainer keine solchen Reports bekommt dann wird er davon ausgehen das seine Arbeit in Ordnung ist bzw kennt die Wünsche der Anwender gar nicht. Auch eine neuere Version die man wünscht kann per Wischlist Bug Report übermittelt werden. Oder eben einfach eine E-Mail an den Maintainer mal schicken, die Jungs beißen nicht und man bekommt sehr häufig sehr schnell eine Antwort.
Auf fast jeder Veranstaltung zu FOSS findet man auch Debian Entwickler, fragt diese Leute, lasst Euch erklären wie Debian intern funktioniert. Und wenn es dabei Schnittmengen gibt wobei Debian profitieren kann umso besser!
Ich denke das einige komplett vergessen das Debian ein Projekt ist, welches komplett zum überwiegenden Teil von Freiwilligen gestemmt wird. Und Arbeit an Paketen passiert nicht von selbst sondern von echten Menschen. Ich kenne keinen Maintainer der abgeneigt wäre wenn andere, nicht direkt im Debian Projekt involvierte Beitragende Hilfe, in welcher Form auch immer, anbieten. Es ist ebenfalls auch relativ einfach selber ein Paket zu pflegen, dazu hat Debian vor einigen Jahren schon den Status eines 'Debian Maintainers' eingeführt. Infos zu den verschiedenen Nomenklaturen der Beitragenden unter https://wiki.debian.org/Maintainers
Viele Beschwerden kommen immer wieder von Personen mit der Begründung Debian hätte nur [*]alte Software. Und das mag partiell stimmen, aber pauschal gesprochen trifft dies einfach nicht zu. Wer meint Software xy ist zu alt kann, nein der sollte sich gerne an den jeweiligen Maintainer oder auch die diversen ML wenden. Es kommt auch vor das Maintainer sogenannt MIA (Missing in Action) sind, sprich aktuell nicht erreichbar. Dies kann dann verschiedene Gründe haben, jedoch kann niemand der im Projekt tätig ist zu etwas gezwungen werden wenn er dies nicht will.
Zur Klärung von Meinungsverschiedenheiten unter den Entwicklern gibt es das TC (Technical Commitee). An dieses kann sich gewendet werden wenn alle andern Optionen einer Lösungsfindung versagt haben. Siehe https://www.debian.org/devel/tech-ctte
Kurzum, wenn jemand ein Problem mit einem Paket hat dann bitte eine Fehlermeldung (Bugreport) absenden! Wenn der Paktemaintainer keine solchen Reports bekommt dann wird er davon ausgehen das seine Arbeit in Ordnung ist bzw kennt die Wünsche der Anwender gar nicht. Auch eine neuere Version die man wünscht kann per Wischlist Bug Report übermittelt werden. Oder eben einfach eine E-Mail an den Maintainer mal schicken, die Jungs beißen nicht und man bekommt sehr häufig sehr schnell eine Antwort.
Auf fast jeder Veranstaltung zu FOSS findet man auch Debian Entwickler, fragt diese Leute, lasst Euch erklären wie Debian intern funktioniert. Und wenn es dabei Schnittmengen gibt wobei Debian profitieren kann umso besser!
Keine Distri schreibt ihre Übersetzung für sich neu, das können die auch gar nicht stemmen. Debian Maintainer werden ist auch nicht so einfach, in der Praxis ist es wie in anderen Projekten auch - die Mannschaft ist durchtränkt von Besserwissern, Sozialwracks und anderen Pack die wie eine Schranke wirken können.
aber nur Provozieren ist destruktiv. Wenigstens ein paar kleine Ansätze zur Verbesserung der Situation wären für mich interessant gewesen.
Ich denke der Ansatz von Debian ist heute einfach nicht mehr zeitgemäß.
Die Software ist schon bei der Veröffentlichung steinalt und dementsprechend ist auch die Sicherheit nicht mehr gewährleistet.
Zumindest für Desktopanwendungen sollte es ein Umdenken geben und hier die jeweils aktuelle Version ausgeliefert werden, damit man sicher über die Releaselebensdauer kommt.
Auf dem Papier mag es zwar nett klingen, den Stand einzufrieren und nur noch Sicherheitslecks zu schließen, in der Praxis sieht es dann aber doch anders aus. Das fängt schon damit an, dass ich mich darauf verlassen muss, dass die Entwickler alle geschlossenen Lücken sauber dokumentieren und sich diese Änderungen immer zurück auf die steinalte Version portieren lassen. Zudem werden ja nicht nur Sicherheitslücken gestopft, sondern auch andere Programmfehler behoben. Als Nutzer sehe ich diese Verbesserungen aber fühestens beim nächsten Hauptrelease.
Man kann es drehen und wenden wie man will, auf dem Desktop würde ich ein Debian nicht einsetzen, da die Software nicht sicher ist.
Ich denke Stabilität kommt bei Systembetreuern nie aus der Mode. Neue Versionen bedeuten oft auch Konfigurationsänderungen oder das irgendwelche Abhängigkeiten kaputt gehen. Wenn einem das System mit jedem Update um die Ohren fliegt dann macht man irgendwann keine Updates mehr.
So alt ist sie nun auch wieder nicht. Bis kurz vor dem Freeze werden noch neue Versionen eingepflegt. Danach werden aber sicherheitsrelevante Patches zurück portiert. Entsprechend ist diese "alte" Software genau so sicher wie aktuelle Software.
Teilweise sogar sicherer. Ich denke da an sowas wie Heartbleed. Die OpenSSL Version die in Debian 6 vorhanden ist war überhaupt nicht anfällig für das Problem. Nur die neuere OpenSSL von Debian 7 musste dann mit einem Sicherheitpatch gefixt werden. Es ist überhaupt nicht selten das neue Funktionen auch neue Fehler enthalten.
Wenn du die Debconf 17 verfolgt hast dürfte dir das Thema Flatpak aufgefallen sein. Das wäre ein Ansatz um eine Mischung aus stabiler Basis und neuem Desktop zu bekommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Aug 2017 um 12:13.Zudem sprach ich explizit vom Desktop, denn den liefert Debian ja auch mit aus.Doch sie ist alt, teilweise sogar sehr alt um nicht zu sagen antik. Vom Freeze bis zur finalen Veröffentlichung vergeht bei Debian aber viel Zeit, da erscheint schon noch die ein oder andere neue Browserversion. Ich halte die alte gepatchte Software zudem nicht für sicherer aus den im ersten Post von mir genannten Gründen. Firefox ist hier das Paradebeispiel wie man es nicht machen sollte.
Meiner Meinung nach sollte man soweit wie möglich auf ESR-Versionen setzen und dann die Fixes auch aus dem Hauptzweig einspielen. Genauso wie man bei anderen Desktopanwendungen zumindest die Minorversionen als Updates bereitstellen sollte. Dort ändern sich auch keine Configs, was im Desktopbereich ohnehin keine große Rolle spielt.
Diese ganzen Containerformate halte ich ebenfalls für kritisch, da sie an der Idee der geteilten Bibliotheken vorbei geht und dann überhaupt niemand mehr weiß in welchem Paket nun anfällige Versionen irgendwelcher Bibliotheken verpackt sind. Dann lieber an zentraler Stelle für alle Anwendungen patchen.
Browser und weitere Webanwendungen werden bei Debian aus Sicherheitserwägungen öfter aktualisiert als der Rest (zumindest bei den Point Releases).
Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Zudem gibt es mit Debian Testing auch die Möglichkeit von etwas das man mit einem Rolling Release vergleichen kann. Sofern kein Freeze vorhanden ist fließen ständig Updates mit neuen Versionen in den Testing Zweig.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Könnte daran liegen, dass Bugfix-Releases idR ohnehin 1:1 durchgereicht werden. Du glaubst doch nicht ernsthaft, dass sich ein Maintainer diese heiden Arbeit mit Backports macht wenn es nicht zwingend erforderlich ist. Backports werden nur dann gemacht wenn der Entwickler mal wieder seine 5 Minuten hatte und eine eindeutige Verhaltensänderung als Bugfix umdeklarieren wollte oder ein Versionsstrang sein EOL durch den Entwickler erreicht.
Sehr einfach. Man kann sich bei tausenden Paketen nicht darauf verlassen das nicht doch irgendwo in dem Minor Bugfix nicht doch irgendwas verändert wurde über das man dann stolpert.
Das klassische Versionsschema war immer Major.Minor.Patchlevel. Dabei sollten sowohl bei Patchlevel als auch Minor keine Inkompatiblen Änderungen enthalten.
Aber wie ich aus Erfahrung mit PHP Versionen weiß stimmt das nicht immer. Der Sprung von PHP 5.3 auf 5.4 war einer der extremsten die ich je gesehen habe, obwohl es nur ein "Minor" Sprung lt. Versionnummer war. Eine Menge Skript mussten angepasst werden da nichts mehr funktionierte. Bei PHP gab es auch Änderungen die nur als Bugfix Releases veröffentlicht wurden aber trotzdem dafür gesorgt haben das bestimmte Skript nicht mehr funktioniert haben.
Allerdings scheinen die Paketmaintainer von PHP auch schon langsam die Nase voll zu haben davon das die Entwickler Sicherheitspatches und andere Bugfixes nicht sauber trennen können. Daher werden die Patchlevel Releases bei PHP direkt durchgereicht.
Und auch bei einiger anderer Software werden Versionsänderungen durchgereicht da der Aufwand zu groß ist alles nach Sicherheitspatches zu durchleuchten.
Für den Desktop sehe ich Debian Stable auch als ungeeignet an.
Es kommen ja noch nicht mal Bugfixes oder Übersetzungsupdates rein.
Wo kommst du denn darauf? Debian pflegt teilweise Softwareversionen weiter, welche Upstream schon lange angekündigt sind.
Was meinst Du hier mit "pflegen" und "angekündigt"?
Glasen meinte wohl "abgekündigt".
Na, was heißt bei Debian schon pflegen? Eben nicht.
Bei Debian werden keine Updates eingepflegt. Nur Sicherheitsaktualisierungen, aber die interessieren mich nicht. Nicht, dass ich den dafür nötigen erheblichen Aufwand geringschätzen würde.
Aber ein sicheres System sehe ich als Voraussetzung an. Unter Updates verstehe ich neue Funktionalität, Fehlerbehebung, verbesserte Übersetzung.....
Wenn man "abgekündigte" Projekte weiter pflegen möchte, so sollte man das upstream oder in einem Fork machen.
Stimmt was die Übersetzung angeht, gerade Stretch ist da unter aller sau.
Hmm, Beispiel?
Ich denke das einige komplett vergessen das Debian ein Projekt ist, welches komplett zum überwiegenden Teil von Freiwilligen gestemmt wird. Und Arbeit an Paketen passiert nicht von selbst sondern von echten Menschen. Ich kenne keinen Maintainer der abgeneigt wäre wenn andere, nicht direkt im Debian Projekt involvierte Beitragende Hilfe, in welcher Form auch immer, anbieten. Es ist ebenfalls auch relativ einfach selber ein Paket zu pflegen, dazu hat Debian vor einigen Jahren schon den Status eines 'Debian Maintainers' eingeführt.
Infos zu den verschiedenen Nomenklaturen der Beitragenden unter https://wiki.debian.org/Maintainers
Viele Beschwerden kommen immer wieder von Personen mit der Begründung Debian hätte nur [*]alte Software. Und das mag partiell stimmen, aber pauschal gesprochen trifft dies einfach nicht zu. Wer meint Software xy ist zu alt kann, nein der sollte sich gerne an den jeweiligen Maintainer oder auch die diversen ML wenden. Es kommt auch vor das Maintainer sogenannt MIA (Missing in Action) sind, sprich aktuell nicht erreichbar. Dies kann dann verschiedene Gründe haben, jedoch kann niemand der im Projekt tätig ist zu etwas gezwungen werden wenn er dies nicht will.
Zur Klärung von Meinungsverschiedenheiten unter den Entwicklern gibt es das TC (Technical Commitee). An dieses kann sich gewendet werden wenn alle andern Optionen einer Lösungsfindung versagt haben.
Siehe https://www.debian.org/devel/tech-ctte
Kurzum, wenn jemand ein Problem mit einem Paket hat dann bitte eine Fehlermeldung (Bugreport) absenden! Wenn der Paktemaintainer keine solchen Reports bekommt dann wird er davon ausgehen das seine Arbeit in Ordnung ist bzw kennt die Wünsche der Anwender gar nicht. Auch eine neuere Version die man wünscht kann per Wischlist Bug Report übermittelt werden. Oder eben einfach eine E-Mail an den Maintainer mal schicken, die Jungs beißen nicht und man bekommt sehr häufig sehr schnell eine Antwort.
Auf fast jeder Veranstaltung zu FOSS findet man auch Debian Entwickler, fragt diese Leute, lasst Euch erklären wie Debian intern funktioniert. Und wenn es dabei Schnittmengen gibt wobei Debian profitieren kann umso besser!
Hmm, Beispiel?
Ich denke das einige komplett vergessen das Debian ein Projekt ist, welches komplett zum überwiegenden Teil von Freiwilligen gestemmt wird. Und Arbeit an Paketen passiert nicht von selbst sondern von echten Menschen. Ich kenne keinen Maintainer der abgeneigt wäre wenn andere, nicht direkt im Debian Projekt involvierte Beitragende Hilfe, in welcher Form auch immer, anbieten. Es ist ebenfalls auch relativ einfach selber ein Paket zu pflegen, dazu hat Debian vor einigen Jahren schon den Status eines 'Debian Maintainers' eingeführt.
Infos zu den verschiedenen Nomenklaturen der Beitragenden unter https://wiki.debian.org/Maintainers
Viele Beschwerden kommen immer wieder von Personen mit der Begründung Debian hätte nur [*]alte Software. Und das mag partiell stimmen, aber pauschal gesprochen trifft dies einfach nicht zu. Wer meint Software xy ist zu alt kann, nein der sollte sich gerne an den jeweiligen Maintainer oder auch die diversen ML wenden. Es kommt auch vor das Maintainer sogenannt MIA (Missing in Action) sind, sprich aktuell nicht erreichbar. Dies kann dann verschiedene Gründe haben, jedoch kann niemand der im Projekt tätig ist zu etwas gezwungen werden wenn er dies nicht will.
Zur Klärung von Meinungsverschiedenheiten unter den Entwicklern gibt es das TC (Technical Commitee). An dieses kann sich gewendet werden wenn alle andern Optionen einer Lösungsfindung versagt haben.
Siehe https://www.debian.org/devel/tech-ctte
Kurzum, wenn jemand ein Problem mit einem Paket hat dann bitte eine Fehlermeldung (Bugreport) absenden! Wenn der Paktemaintainer keine solchen Reports bekommt dann wird er davon ausgehen das seine Arbeit in Ordnung ist bzw kennt die Wünsche der Anwender gar nicht. Auch eine neuere Version die man wünscht kann per Wischlist Bug Report übermittelt werden. Oder eben einfach eine E-Mail an den Maintainer mal schicken, die Jungs beißen nicht und man bekommt sehr häufig sehr schnell eine Antwort.
Auf fast jeder Veranstaltung zu FOSS findet man auch Debian Entwickler, fragt diese Leute, lasst Euch erklären wie Debian intern funktioniert. Und wenn es dabei Schnittmengen gibt wobei Debian profitieren kann umso besser!
Beispiel: seahorse, system-config-printer
Keine Distri schreibt ihre Übersetzung für sich neu, das können die auch gar nicht stemmen. Debian Maintainer werden ist auch nicht so einfach, in der Praxis ist es wie in anderen Projekten auch - die Mannschaft ist durchtränkt von Besserwissern, Sozialwracks und anderen Pack die wie eine Schranke wirken können.