-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Dec 2005 20:12:51 +0100 "David C. Weichert" <[EMAIL PROTECTED]> wrote:
> Am Dienstag, den 20.12.2005, 18:11 +0100 schrieb Jonas Smedegaard: > > On Tue, 20 Dec 2005 15:50:39 +0100 > > Finn-Arne Johansen <[EMAIL PROTECTED]> wrote: > > > > > Jonas Smedegaard wrote: > > > > On Tue, 20 Dec 2005 12:58:44 +0100 > > > > Steffen Joeris <[EMAIL PROTECTED]> wrote: > > > > > > > > Debian has a bug tracker: http://bts.debian.org/ . Let's use > > > > that, and request one or more pseudo-packages created for > > > > Skolelinux instrastructural meta bugs. What we win is easier > > > > integration with Debian - 'cause our end goal is complete > > > > absorbtion into Debian, right? > > > > > > OK, this is an interesting point. We have our own packages that we > > > work on on a daily basis. And most, if not all of them are also > > > uploaded into Debian. At some point I filed a bug on a package > > > that we uses in debian-edu, but we used a newer than the one in > > > debian-unstable. I dont remember if our maintainer called me, or > > > if it was on irc (i could find out if you want to know), and was > > > really angry, because I had filed a bug on a version that he not > > > yet had uploaded into debian. He told me that I could get > > > blacklisted from bts from that. Do we want that to happen with > > > our users ? I dont. > > > > Bugs filed against something not in Debian must at most be a minor > > issue when "most, if not all [.. are ..] uploaded into Debian" as > > you claim. > > > > Seriously, the cooperation with Debian should naturally be in > > awareness of those involved: Expecting the Debian developer to know > > about your unofficial hack to her package is imposing additional > > work on her - which is rude. So the anger is (to some extend) > > understandable. > > > > Instead, working with the package maintainer would be better. If the > > package was group-maintained you could offer to prepare parallel > > releases of the package with the Debian-edu hacks included, and also > > take care of the bugreports ticking in (from Debian-edu users or > > others) against such experimental package until it was deemed > > suitable for mainstream. > > > > In an ideal world I'd agree. But what chance do the experts see that > what Jonas wrote is possible with the LDAP package? Or do I think it > is more complicated than it actually is? The "experts" here probably is the maintainers of the ldap package itself, as this is more of a social challenge than a technical one. So cc'ing this to the openldap2.2 maintainer for input. Torsten: The issue discussed here is that Debian-edu maintains a separate bug tracking system for its fork of openldap, and wether it would be possible to work more closely with Debian. It is my understanding[1] that the concrete reason to fork openldap for the Woody-based Skolelinux is no longer relevant, but if new hacks would be needed for a sarge-based debian-edu today, how would you then feel about making room for a specially-featured variant of your package released for experiemental? If you didn't want the extra burden yourself then a possible approach would be making the package team-maintained and let others deal with the different bugreports and prepare the experimental package for you to upload. I am aware that the use of experimental is a hack (what to do if debian-edu and debian-tiny wants different forks of same package?), but I see that as a positive challenge within Debian, rather than the current situation of Debian-edu IMO drifting off from Debian (bugs filed at one BTS may apply to the other as well). - Jonas [1] http://developer.skolelinux.no/info/cdbygging/sl-packages.txt - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDqHc1n7DbMsAkQLgRAuswAJ9bS2Nxoo+b+7jIuK7FpEStWbXLbQCgnqjd UHX+D9Z827xRjifwRKj80Is= =rlaE -----END PGP SIGNATURE-----
