Hello Philipp & List(s), On Thu, Jun 24, 2010 at 09:50:24AM +0200, Philipp Huebner wrote: > Hey all, > > > Last Sunday there was a meeting of all the parties involved with the > Skolelinux-RLP project. The main topics discussed were the current > status of Skolelinux-RLP and how to move on from now, with the > importance of sustainability in mind when the project ends (from the > governmental side) in February 2011. > > A rather drastic change of course was decided, which hopefully will help > the RLP project as well as the international Debian Edu project.
I may add that I had also very drastic concerns because of sustainability and keeping deadlines, which can be problematic if you rely totally on volunteers for critical features and quality of the base system, instead of maintaining your own base independently, with binding to the community work of course. The following things you said are already documented (partly) in the http://rp.skolelinux.de/ wiki at https://rp.skolelinux.de/rlp-wiki/bin/view/RlpSkolelinuxPublic/NeueVorgabenPhase3 https://rp.skolelinux.de/rlp-wiki/bin/view/RlpSkolelinuxPublic/VorgehenInstallationPhase3 (Currently in German language only, sorry). > These are the most important things that have been decided: > > 1) Installation > ---------------- > From now on, Skolelinux 5 will be the base for all new installations, > using the DVD for the main-server, and optionally PXE for the other > installations. > No more pre-/self-built images :) I am very concerned about your surely well-meant smiley here. The image-based system was a good proof-of-concept, to show immediately the working entity of server and clients in a virtualized or real network, including all new features preconfigured to "just work out of the box", plus very fast installation option. I don't think that installation and setup will work that quick with the new requirements, though I would be very relieved if results prove me wrong. This is of course a real-life-school-installation concern, not a development concern. On the development side, you are of course absolutely right. The best way to gain feedback is a complete self-conducted installation and configuration, with all the learning effects involved. > 2) Features + Documentation > ---------------------------- > All features that were/are being developed for the specific requirements > of RLP shall be documented soon in the wiki. Until now, they were > built-in with the images and hard to use/implement by other parties. > In the future it shall be easier for everybody to use these features, if > required. Correction: MOST of the new features were already provided as installable packages in Debian-format, though because of their nature of requiring changes in config files not owned by them, were not possible to build as Debian packages by a DM (at least this is what I was told). So, after installation of italc-rlp and linbo packages from our website, a round of configuration, key management and tests must follow in order to make the addons work, and this will probably not change with the new method. The only difference is that supporters will have to conduct every single step all by themselves instead of using a preinstalled system. Some changes, like workarounds for slow NFS over WLAN, are problematic to package because they have no "software" included, and are rather requirements and configuration addons. For example, we require(d) a kernel with cachefilesd feature working for NFS filesystem caching (mount option fsc). I believe that things like this will rather be documented and implemented by skillful installers instead of being integrated in packages. See https://rp.skolelinux.de/rlp-wiki/bin/view/RlpSkolelinuxPublic/NetworkPerformanceTuning . So, documentation and HOWTO generation now becomes more important than a working prebuilt system in our RLP project. > Specially developed software shall be offered as packages for Skolelinux 5. > The RLP specific documentation shall be put into a package, similar to > debian-edu-doc. > These packages will be made available on > http://rp.skolelinux.de/packages/. Naturally, the amount of packages > shall be kept to a minimum, to stay as close to Skolelinux as possible. > What can go into Debian shall go there. > > An AddOn-CD shall be created, containing the material to add the RLP > flavour to Skolelinux 5. Adding: The documentation package(s) and the Addon-CD (which Christian Külker promised to provide a "Hook Howto" for) will be built autmatically from what's in the repository and Wiki, to avoid duplicate work. > 3) Discussions > --------------- > Furthermore, all future discussions shall take place on the known public > mailinglists (as opposed to the private mailinglists before). This somewhat sounds as if our development and supporter mailinglists were "secret", which is not the case. It was just reducing overhead to keep RLP-specific issues to RLP-involved people, rather than having the usual threads about how to write "PS" correctly and analysis of attitude on psychological levels instead of discussing the technical problem that was asked about. You know what I'm talking about. Smiley here. ;-) I would be happy to see discussions on a mainly technical level in the future, though "hope" is not something we can really rely on in software engineering. > So expect some more traffic on [email protected] in the > future, as well as on [email protected] and [email protected]. > > 4) Bugtracking > --------------- > Bugtracking shall be improved. Bugs are reported directly to the BTS / > the bugzilla if their root is in Debian / Skolelinux. Wishlist bugs and > problems with the RLP specific features shall continue to be tracked on > http://rp.skolelinux.de/trac/ Correct, thanks for clarifying. On http://wiki.skolelinux.de/RLPBugsHowto, it still looks like all Bugs, regardless if related to our changes and addons, should be reported through the RLP trac, which makes no sense, because we would have to directly close the bug as "wontfix" and reroute it to the Debian bugzilla, following the standard bugreporting policy recommended on the other "Bug report Howto" pages (http://wiki.skolelinux.de/BugReporting). So, reporting via the standard Debian mechanisms and the public mailinglists should be the first choice, and reporting to RLP if it turns out to be a bug specifically in our addons only should be the second choice. > Bottom line > ------------- > The overall goal is to make the project more sustainable. For this it is > important not to be a "fork of a fork", but rather be a flavour of the > "real" Skolelinux, which itself is trying to become a Debian Pure Blend > for the same reason. Technically, for me it is still the "fork of a fork" (Skolelinux is a fork of Debian, Skolelinux-RLP now is a fork of Skolelinux). You can call it "flavour", but is makes no technical difference if systems are in fact still different and there is no working longterm dist-upgrade. > The RLP project is still rather young and might lack some experience > about how to accomplish this. Any guidance, help and assistance for > self-help is welcome. This is a great chance to give a new push of life > and manpower to Debian Edu, let's work together and use this chance! As a final remark in this answer: This is a project with fixed and very tight deadlines that are not set by ourselves (installation dates at schools, quick solutions and workaround in order not to miss a single lesson at school because of software defects), so I am very excited about how this is going to work with a lot of the necessary software engineering process given away to the user/developer community. But I'll try my best to comply with the rules and policies, as always. :-) Regards -Klaus -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
