Hi, For those joining in on debian-edu@l.d.o, this thread started on debian-custom@l.d.o and I'm crossposting this now, as I think it's relevant for Debian Edu development. Phillip and Luk, _you_ can skip the first quote+reply pair after this intro and just read the second :-) (There are three in total, the last is very short.) And as you all probably would have figured out yourself at some time, when I use "our" in the paragraphs below, I mean "Debian Edu" :-) On Friday 04 April 2008 15:21, Otavio Salvador wrote: > Holger Levsen <holger@layer-acht.org> writes: > > To throw in another thought I had last night, after our discussion: > > Debian Edu is not 99,867% Debian as I wrote yesterday, but 100%. It's an > > official Debian subproject, so it is Debian. It only takes 99,867% from > > stable and stable-updates, and the rest is from our archive, which is an > > official archive of an official Debian subproject. There are other > > official archives too: volatile comes to mind, and hopefully backports > > will soon be official too. > I'm sorry but Debian-Edu archive aren't part of Debian archive fully. Please read again and imagine I had written "and the rest is from our archive, which is an archive of an official Debian subproject"... :) Hmm, still, guess I can just claim Debian Edu is part of Debian. And unlike volatile and ftp.debian.org we dont differate between main, contrib and non-free, we only have a "local" section. In our http://wiki.debian.org/DebianEdu/ArchivePolicy we demand that uploaders have to comply to the DFSG, and usually we follow the Debian ftpmasters reject FAQ, but we might make exceptions. (See #1, #4 and #12 of the policy.) Currently we only have packages in local which are fine for Debian main, but flashplugin-nonfree-extrasound is waiting in etch-test (our equivalent to stable-proposed-updates in Debian) to be moved to etch. ATM this is stalled on the question if we should accept a package which is waiting in Debians NEW queue since two months. In Debian it's clear the package will go to contrib (as it depends on flashplugin-nonfree), it's "only" stalled because of maintainance/packaging questions. But for me a new question has popped up: do we want to "polute" Debian Edu etch with a contrib package? It's not installed by default, but still, it's ugly ;-) I guess we still want to do this, as our priorities are free software and our users :-) ftpmaster@skolelinux, how/when will we decide on the flashplugin-nonfree-extrasound package? Do we want it in etch, even though there might be no upgrade path? I now think so: either the upgrade path will be free flash or we will need to find a way to have a upgrade path to flashplugin-nonfree-extrasound or whatever the package name will be. Comments? (It has been tested and works, too tired to provide URLs for this.) For Lenny I suggest to rename our "local" to "main" and to create contrib and non-free when we need them. (Rationale for the 2nd part: we are aiming for a free flash in Lenny, don't we? ;) > > Also there is the issue that Debian Edu might release within Lenny, but > > then produce independent pointreleases of it afterwards. (Then we will > > again have less than 100% of our packages from main, security updatdes > > and volatile.) And then we might also use packages during development, > > which are not yet in Debian (cause they are stuck in NEW in Debian or > > whatever.) > The point releases might need to be coordinated with SRM team and get > the changes on Debian and then build from it. That's the way I see it. For etch we have done point releases indepentenly (and will continue to do so, "btw" we should talk about a etchandahalf based pointrelease and new installation medias..), and IMHO quite good. So technically we are captable of doing this. Of course it would be great (as we would avoid duplication of work and thus could get more work done :) if we could get the changes we need into Debian pointreleases for Lenny, which are fixes for important or trivial bugs in the Debian Edu configuration mostly, plus usally some bugfixes for broken packages used on the desktop or in our services, which would also fit Debian pointreleases nicely, for examples see http://wiki.debian.org/DebianEdu/Status/Etch (*) Though of course, for this to happen, we first need to manage to release Debian Edu Lenny with(in) Debian Lenny.(!) Currently 4 out of 9 packages in our "main labeled section" on http://qa.debian.org/developer.php?login=debian-edu@lists.debian.org are not in Lenny with the version in unstable, which is (for all 9 packages there) irrelevant for the Debian Lenny release, but we can't release without those 9 packages well in shape. So we will need to work on this :-) That said, and if we manage to do this, what would the SRMs think about a laxer pointrelease policy for "Debian Edu packages as in the main section on our QA page"? We would like to be able to fix trivial, wishlist, minor and normal bugs too :-) Of course, in the end this is true for any package. But I believe there are some packages for Debian in which (even small) bugfixes in pointreleases have a much higher impact on the user experience. To those I consider the Debian Edu group of packages, other CDD meta packages, documentation packages, fai (a non-interactive system to install a Debian infrastructures...). (*) I shall cleanup the known bugs section in the Edu etch status page tomorrow (or rather, mention when that part was last edited...) Everything above that section is up2date. > > And there might be nonfree blends. > Pure Non-Free Debian Blend looks... c r a z y ;-) I dont think anybody suggest those / this category - certainly not me :-) regards, Holger
Attachment:
pgpNOchFdPbq5.pgp
Description: PGP signature