Hi Klaus, On So 11 Sep 2011 01:31:44 CEST Klaus Knopper wrote:
>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, dassDa 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?
Hier kurz mal die Liste derjenigen, die auf Debian Edu SVN Schreibzugriff haben (>=4 ;-) ), darunter bestimmt einige Karteileichen:
mike-gabriel-guest@vasks:~$ getent group debian-edu debian-edu:x:40003:pravi-guest,white,holger,werner,pere,andreas,sep-guest,arntog-guest,lfaraone,ffm-guest,janr-guest,olea-guest,vincent-guest,fenio-guest,debalance,mike-gabriel-guest,osevoll-guest,dalatun-guest,sandven-guest,tatotat-guest,elzapp-guest,sveinung-guest,hertzog,neitzsche-guest,n0rman-guest,xoswald,alfton-guest,odd-guest,tille,jredrejo,chrisgoes-guest,js,hansfn-guest,danielsan-guest,oehler-guest,luk,jever-guest,andi-guest,ludger-guest,philippefalvo-guest,geoffrey-gouez-guest,jeromef-guest,thegve-guest,kaplan,totom-guest,olivier54-guest,vinci-guest,pneff-guest,rafl,axelb-guest,lazyboy-guest,vb-guest,haraldt-guest,toresbe-guest,mkoch-guest,andread-guest,joe-guest,christian-guest,de-build-guest,vagrant-guest,hilaire-guest,klausade-guest,bilbo,mariwan-guest,bgrotan-guest,ragnar-guest,jemtland-guest,korsvoll-guest,roktas-guest,gaute-guest,alexbr-guest,barbaross-guest,mkotsbak-guest,runesk-guest,finnarne-guest,aracnus-guest,k4x-guest,cobaco-guest,seppy,guillem,otavio,keybuk,bah ner,bubulle,tfheen,aigarius,markos,luther,knopper-guest,antjac-guest,rousseau-guest,birdy-guest,ralfg-guest,jeansieg-guest,lewis-guest,xoraxax-guest,ajqlee,karbon-guest,winnie,jss-guest,morten_arnesen-guest,alee-guest,lambda-guest,rfteichert-guest,sthierry-guest,fhet-guest,blankoworld-guest,schasi-guest,knuty-guest,claush-guest,vagrant
(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.
Dann besteht hier doch ein Forschungsraum, den wir ausfüllen können. Für wheezy sollten wir diese Diskussion unbedingt führen und konstruktiv gestalten!!!
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.
Debian Edu ist ein Debian Blend, das heißt, es baut in der nativen Form vollständig auf Debian auf. Da Debian Edu sich immer auf die aktuelle Stable Distro Version, baut es auf Paketen in Debian Stable (also aktuell squeeze) auf. Pakete, die nicht in Debian sind, müssen in Debian hochgeladen werden (nach Debianischem Procedere unter Berücksichtigung der Debian Policies), dann müssen sie in Debian den Zyklus bis in die Stable Version durchlaufen, dann können sie in Debian Edu verwendet werden.
Für ein drei Jahres Projekt ist diese Timeline natürlich eng und es braucht dann im Projekt eigentlich direkt einen Debian Developer, der (a) als beratender Debian Policy Stratege mit der Projektleitung in einem Boot sitzt und (b) dann auch die Pakete, die ihr beifügt, in Debian direkt hochlädt und dann auch maintained.
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.
Ich war im letzten Jahr mal in Bremen und habe mir die Fa. Univention angeschaut. Die bauen unter großem Aufwand eine eigene Distribution auf, alles unter AGPL. Theoretisch könnte man die Management Software des Servers (ein Super-mächtiges Tool) auch auf Debian Portieren und forken und all so ein Zeugs.... Der Aufwand, sich in Fremd-Software einzuarbeiten, ist immens. Diesen Aufwand scheue ich persönlich und vielleicht auch andere, wenn nicht absehbar ist, ob der Nutzen hinterher angemessen hoch ist. Hmmm... Für die Community wäre es ein viel größerer Gewinn, wenn aus dem Projekt selbst jemand aktiv wäre und eine Software an die Community übergeben würde.
Meiner Ansicht nach muss in Projekten, die ein Überleben der Ergebnisse über das Projektende hinaus sichern wollen, dafür sorgen, dass die Ergebnisse an einem Ort landen, an dem evtl. andere die Ergebnisse weiterpflegen und so dort auch Paten gefunden werden für den erstellten Code. Debian liefert hierfür eine 1a Projektstruktur.
>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.
Für wheezy sollten wir diese Diskussion erneut führen!!!!! Hast du mal einen Link für eine Feature-Liste, die ihr in eurem RLP-Overlay drin habt. Einige habe ich im Kopf, aber einen aktuellen Stand zu bekommen, wäre gut.
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. :-)
CipUX ist in unstable, wir entwickeln aktuell an Debian Edu stable... So direkt hätten wir CipUX in Debian Edu (bei Beibehaltung der Debian Blend Policy) nicht verwenden können.
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.
Ein GOsa²/FusionDirectory Developer ist aktives Debian Edu Developer Mitglied (Alejandro Aescanero). Er hat auch das Netgroups Plugin für GOsa² auf unsere Anfrage beigesteuert. Was auch immer es braucht, ich denke, dass wir mit Alejandro Absprachen und Wege finden können, Features in GOsa² (bzw. evtl. später FusionDirectory) zu implementieren.
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.
Strenger Richtlinien in Deutschland widersprechen keiner Aufnahmen im Debian Edu Kernprojekt. Kann sein, dass dann andere Menschen aus anderen Ländern etwas wettern über das strenge, bürokratische Deutschland. ,,Deutsche'' Funktionen, die leichtens abschaltbar (oder per default nicht eingeschaltet), können durchaus ein Bestandteil des Kernprojekts werden (solange sie nichts anderes kaputt machen, sich an Debian Policies halten, etc. pp.).
>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. :-)
:-)
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. :-)
Die Kundenprojekt vs. Freies Projekt Problematik begegnet mir täglich im X2go Projekt. Den Punkt kriege ich komplett und da muss man Wege finden und meistens duale Wege. Acknowlegded!
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.
Da ihr da ähnliche Pläne hegt, sollten wir uns für Debian Edu wheezy unbedingt zusammen finden!!! (Zum Kernel: ist der Poly-Instance Kernel nicht auf dem Speiseplan für Debian wheezy? Ich meine schon...)
Viele Grüße -Klaus
Grüße zurück, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
Attachment:
pgpxs8HozEihD.pgp
Description: Digitale PGP-Unterschrift