Re: Macht euch bereit, ganz bald Debian Edu squeeze (beta1) zu testen...
Hi Mike,
Habe mir gedacht, dass das ein längerer Thread werden könnte. ;-)
On Sat, Sep 10, 2011 at 07:02:42PM +0200, Mike Gabriel wrote:
> Hi Klaus,
>
> On Sa 10 Sep 2011 18:11:22 CEST Klaus Knopper wrote:
>
> >>Insgesamt finde ich es sehr sehr schade, dass man von euch aus RLP
> >>relativ wenig Feedback auf den internationalen Debian Edu Kanälen
> >>mitbekommt (IRC, Debian Edu ML, Debian Edu Wiki(?)) und das von
> >>eurer Seite auch bislang -- aus meiner Sicht -- nicht viele Beiträge
> >>in die neue Version eingeflossen sind (hier kann ich mich echt
> >>irren, weil ich nicht voll auf Stand bin). Ihr habt da bestimmt
> >>einige super-gute Ideen rund um Skolelinux in RLP umgesetzt, aber
> >>leider haben alle Skoletuxe außer die in RLP nicht wirklich was
> >>davon. Für Debian Edu squeeze da noch was dran zu ändern, ist so
> >>kurz vor dem Release nicht mehr möglich, aber für Debian Edu wheezy
> >>würde ich mir wünschen, dass wir gemeinsam EIN Debian Edu wheezy
> >>entwickeln.
> >
>
> >Wir haben eigentlich auf den "in persona"-Treffen sowie auf der
> >Entwicklerliste ziemlich viele Vorschläge eingebracht, die leider nicht
> >auf größeres Interesse seitens des Skolelinux-Entwicklerkernteams
> >gestoßen sind. Ich persönlich war auch gelegentlich im IRC zu Gast.
>
> Das was in Debian Edu zählt ist, dass du am Code arbeitest und Dinge
> committest die dann (a) funktionieren (hier muss Mike hoffen, dass
Da liegt wohl eines der Probleme, denn die Zahl derer, die etwas ohne
einen "Paten" in Skolelinux commiten können bzw. das in den letzten 2
Jahren tatsächlich getan haben liegt, dich eingeschlossen, nach meinen
letzten Hochrechnungen bei etwa ... 4?
> Holger und Petter das nicht lesen),
Der war wohl eher für Insider. ;-)
> (b) auch von den anderen als
> sinnvoll oder gewinnbringend erachtet werden und (c) nicht irgendwas
> kaputtspielen, was andere innerhalb von debian-edu aufgebaut haben.
Da sind schon einige constraints, neben dem notwendigen Fachwissen (das
traue ich mir noch zu) das globalen Verständnis um die Philosophie von
Skolelinux sowie die Entwicklungsstrategie bezüglich "technisch möglich"
vs. "gewollt" - hier blicke ich selbst nicht ganz durch die Hierarchie
durch, zugegeben.
> >Aus meiner Sicht waren die Diskussionen im Ergebnis ernüchternd. Unsere
> >Ansprüche bezüglich Sicherheit bzw. Datenschutzrichtlinien in RLP seien
> >"paranoid", der Klassenarbeitsmodus "unnötig" (weil man ja auch einfach
> >public-Austauschverzeichnisse benutzen könne, die regelmäßig gelöscht
>
> Ich denke, wenn während der Entwicklungsphase von d-e squeeze
> funktionale Commits zum Thema gekommen wären, dann hätte das
> bestimmt viele erfreut.
Wir haben darüber auf den Treffen schon gesprochen, und sind bei "Wie/wo
kann ich unseren Code sofort committen" steckengeblieben, weil wohl
einige Dependencies problematisch waren, die für das RLP-Projekt weniger
ein Problem waren als für Skolelinux allgemein.
> Wichtig ist, dass solche Neuerungen (a) auf
> Paketen in Debian aufbauen und (b) von euch in Debian Edu SVN
> eingepflegt werden. Die Relevanz von Vorschlägen kann aber alleinig
> nur im Tun gemessen werden: nur ein Vorschlag auf den eine
> Umsetzung/Handlung (d.h. ein SVN Commit auf
> svn.debian.org/debian-edu) folgt hat in diesem Kontext Relevanz.
> Alles andere ist nett und inspirierend aber nicht nachhaltig
> zielführend aus Sicht des Debian Edu/Skolelinux Projekts.
Siehst Du, da haben wir es wieder... Ich denke, da gibt's v.a.
Unterschiede in der Interpretation des Begriffes "nachhaltig". Wir
wollen, genau wie ihr, etwas haben, was in >= 10 Jahren immer noch
funktioniert und wartbar ist. Deswegen bauen wir mit relativ hohem
Aufwand Anleitungen sowie Pakete im Debian-Format, die sowohl unter
Skolelinux als auch vanilla Debian installationsfähig sind. Das reicht
aber nicht, um in Skolelinux aufgenommen zu werden, habe ich gelernt.
> >werden, oder lieber gleich moodlen), dann war unser CipUX nicht gut
> >genug als LDAP-Middleware und sowas wie Quotas für Drucker oder
> >Festplattenplatz, Profile für Klassen und Fächern, Klassenversetzung
> >nach jedem Schuljahr zu "speziell". Na gut, vielleicht haben wir in RLP
> >halt einfach "zu hohe Ansprüche" an ein Schul-Linux gehabt, sei's drum.
>
> Nein, ihr bestimmt sehr sehr gute Ansprüche. Und ihr habt nicht in
> Debian Edu SVN committed.
Ging leider nicht, deswegen haben wir eben ein eigenes Repository.
> That's it. Nur aus diesem Grund ist GOsa²
> jetzt in Debian Edu das Rundum-Tool für die LDAP-Verwaltung. Denn:
> die GOsa²-Implementierung wurde in Debian Edu SVN committed. Again:
> Do-Ocracy. Handlung liefert messbare Ergebnisse.
Es ist wohl eher die Frage, wer näher am "Kern" sitzt und eine
entsprechende Entscheidungsgewalt hat, und da CipUX ja offiziell in
Debian/unstable ist, kann's eigentlich kein technischer Grund gewesen
sein. Unsere messbaren Ergebnisse liegen daher halt derzeit nur auf
unserem Server. :-)
Ich finde übrigens GOsa² als Webgui prinzipiell gut, kannte GOsa auch
schon vorher, es war vor vielen Jahren einmal auf der Knoppix-CD mit den
notwendigen LDAP-Datenstrukturen vorinstalliert mit dabei. Es macht halt
leider nicht alles, was wir damals für unsere Erweiterungen gebraucht
haben, und kam gut 2 Jahre zu spät in Skolelinux an.
> >Wir haben dann schließlich die genannten Erweiterungen alleine gemacht,
> >und unsere Ergebnisse und Erkenntnisse auf der Webseite
> >http://rp.skolelinux.de/ zur allgemeinen Verwendung publiziert. Unsere
>
> Das klingt jetzt ein wenig frustriert und resigniert...
Keineswegs! Man lernt mit der Zeit, mit den vorhandenen Strukturen zu
arbeiten und sich über (fast) nichts mehr aufzuregen. Alles ist gut so,
wie es ist. :-)
> >Schulen verwenden offiziell ein nach Pflichtenheft modifiziertes
> >Skolelinux/Lenny auf der Serverseite (mit CipUX und unseren
> >RLP-Erweiterungen) und Debian/Squeeze (ebenfalls mit
> >Erweiterungspaketen) auf der Clientseits.
>
> Natürlich kann eine Musterlösung für ein Bundesland nicht komplett
> in Debian Edu umgesetzt werden, dafür ist der Projektkontext zu
> international und die Anforderungen in RLP (wie wohl auch in jedem
> anderen Bundesland) zu spezifisch.
Ja. Dinge, die modular sind, können als Add-Ons irgendwann in Skolelinux
Einzug finden, und anderes, was fundamental anders ist, muss eben im
Resultat als weiteres "Derivative" herhalten.
> Ein Overlay muss bei sowas wohl
> immer her. Aber die Frage ist, wie groß ist das Overlay (als die
> spez. Anpassungen) und wie groß der Beitrag zum Kernprojekt.
Die Richtung ist wohl teilweise unterschiedlich. Wir haben in
Deutschland halt nun mal ziemlich umfangreiche Anforderungen an den
Datenschutz und halb-öffentliche Netzzugänge, und wollen auch
nachvollziehbar sichere Prüfungen am Rechner durchführen, das schreiben
die Prüfungsordnungen auch vor, ansonsten müssen wir bei Prüfungen auf
Papier bleiben und Skolelinux würde in dieser Richtung auch einfach
keinen rechtfertigbaren Mehrwert bieten.
> >Das Grundproblem, dass, wie bei Skolelinux auch, der Server komplett neu
> >installiert werden muss, wenn ein neues Major-Release ansteht, haben wir
> >leider auch weiter, daher tendiere ich persönlich dazu, in Zukunft eher
>
> Das Problem ist in der Tat ein Problem.
Wie wir uns wieder einig sind. :-)
> >ein "richtiges" Debian mit "Skolelinux-Netzwerk" Konfiguration auf der
> >Serverseite zu verwenden, da wir viele der "Eigenheiten" von Skolelinux
> >wiederum für unsere Schulen gar nicht brauchen, aber die Kompatibilität
> >mit Skolelinux schon erhalten wollen (es ist z.B. durchaus von Vorteil,
> >die Netzwerkstruktur exakt festzulegen, um Fehlern leichter auf die Spur
> >zu kommen).
>
> Beim letzten Entwickler-Treffen in HH haben Andreas Mundt und ich
> davon gesponnen, das Hauptpaket von Debian Edu: debian-edu-config
> komplett auseinanderzunehmen von from-scratch neu aufzubauen.
> Sollten sich wirklich Freiwillige an solch ein Mammut-Projekt
> heranmachen, dann könnte eine Policy sein, Upgrade-Fähigkeit in den
> meisten Bereichen/Teilpaketen zu definieren und zu forcieren. Aber
> für solcherlei Visionen ist das noch zu früh.
Da liegt ein weiteres Problem: Wir hatten in unserem Projekt nur 3 Jahre
Zeit und feste Deadlines für die Ergebnisse. Das ist mit reiner
Community-Arbeit schier unmöglich einzuhalten. Daher sehe ich unsere
Ergebnisse im schlimmsten Falle als ein Motivationsprojekt für die
Community, es anders noch besser hinzubekommen, als wir es mit unseren
strengen Vorgaben in der kurzen Zeit geschafft haben. :-)
Ein neuer Ansatz könnte tatsächlich ein "normales" Debian from scratch
mit entsprechendem Preseeding sein, auf das die neuen Funktionen als
Pakete oder Upgrades (wir brauchen für den Prüfungsmodus beispielsweise
eine andere Kernel-Konfiguration für Poly-Instanzierung) upgradefähig
aufgepflanzt werden. Das wird aber eher ein neues Projekt sein.
Viele Grüße
-Klaus
Reply to: