Re: Report from the Skolelinux project in Rhineland-Palatinate (RLP), Germany
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 debian-edu@lists.debian.org in the
> future, as well as on user@skolelinux.de and cipux-devel@cipux.org.
>
> 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
Reply to: