[Pkg-openldap-devel] [dr@jones.dk: Re: the .org proposal or "join
forces"]
Torsten Landschoff
torsten at debian.org
Thu Dec 22 10:29:42 UTC 2005
FYI
----- Forwarded message from Jonas Smedegaard <dr at jones.dk> -----
X-Original-To: torsten at localhost
X-Flags: 0000
Date: Tue, 20 Dec 2005 22:41:01 +0100
From: Jonas Smedegaard <dr at jones.dk>
To: debian-edu at lists.debian.org
Cc: openldap2.2 at packages.debian.org
Subject: Re: the .org proposal or "join forces"
Organization: Spiff ApS
X-Face: yvw#o~hz'%$;u|iUBohl)T/ow at lBXi/j&/v4H;'#{E\]pJHQsA0!FKs"='cNj!x=\]NiEsi
PWi#:wS|bY F]0)w+?QXNQi={<6HVU5(98,?_#=d!$YOQ"9Vc%Ax-!?lWZUMj7y}m
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at jones.dk
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: -2 (not scanned, spam filter disabled)
X-GMX-UID: Ix/aY+FKeSEkQ+5/YnQhaXN1IGRvb8Do
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on stargate.galaxy
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.3
-----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 at 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 at bzz.no> wrote:
> >
> > > Jonas Smedegaard wrote:
> > > > On Tue, 20 Dec 2005 12:58:44 +0100
> > > > Steffen Joeris <Steffen.Joeris at 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-----
----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20051222/a7ed28e0/attachment.pgp
More information about the Pkg-openldap-devel
mailing list