[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the .org proposal or "join forces"



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[sent again with correct address of openldap2.2]

On Tue, 20 Dec 2005 20:12:51 +0100
"David C. Weichert" <dcweichert@freenet.de> 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 <faj@bzz.no> wrote:
> > 
> > > Jonas Smedegaard wrote:
> > > > On Tue, 20 Dec 2005 12:58:44 +0100
> > > > Steffen Joeris <Steffen.Joeris@skolelinux.de> 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)

iD8DBQFDqHptn7DbMsAkQLgRAjaAAJ9kAESPLQ1/dJiYn21Eew2jtnfnrACfXXfB
RDdpgvPFcY2rPRqO3mt2gQ0=
=dwUt
-----END PGP SIGNATURE-----



Reply to: