Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of elecharny@gmail.com designates
 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hD7uqYFqbTyIR/kbvLwgiZQ1wLCVkBSE3zIIEiAaVet1YcX35my8fSY3JkYu8zbz7WbVI0F8N5SR4oLQy2R0Ic5XQvkPvZQSroVMYxxGd6l7icrtqpLV6IcUJOvMnqD9SnnSaQO1I9lenyCJtjryS+McWXEZUQsZracsEP6Qrb8=
Message-ID: <d45b08f00705230255k1d64c782icbf990984ee6935@mail.gmail.com>
Date: Wed, 23 May 2007 11:55:10 +0200
From: "Emmanuel Lecharny" <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [VOTE] Policy for Managing TLP POM
In-Reply-To: <a1b4a6610705230155r2507d86xaf0e16af8b635b2f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <a32f6b020705221800j5cc9e0a0v645d9fd220fbf812@mail.gmail.com>
	 <a1b4a6610705230155r2507d86xaf0e16af8b635b2f@mail.gmail.com>

I will abstain right now, (make it -0), not that I find your proposal
insane, but I have some suggestion and concerns that should be
addressed :

- let's document the actual hierarchy of the project in confluence. We
have done that once upon a time, it's now time to do it again, would
it be for Chris only ...
- we should document the content of this pom on confluence,
- keep this pom as simplest as possible
- remove the branch and trunk section of
http://svn.apache.org/viewvc/directory/tlp-common, just keeping the
release (this is a proposal, I'm not 100% sure this is the perfect
idea)
- I don't really understand the "3. Do not copy the TLP POM in SVN".
If it means we will just push the TLP pom to maven repo, then it can
become a pb. I would rather prefer respect my previous point
- applying this policy to the project means we will need some script
to build ADS as a whole. It will be a versy simple script, building
shared, daemon, kerberos and then apacheds. Otherwise, it will be
painfull for users ...
- I also have a little concern about Eclipse generated files. If we
don't have the possibility to generate them with a common pom, then
fdebugging will start to become a big issue, if we have to grab the
sources from jars instead of projects : you will be asked for those
sources when entering in shared for instance. This is not something I
would like to do, as I'm quite involved in shared ...

Ok, this points may not be valid, but at least we should discard them
before going farther !

Thanks Alex for having created this page, and for having endorsed the
task. It's obviously someting we should have done before, but there is
no better time to do it than as fast as possible ...

btw, this page exists because yesturday we tried to cut the 1.0.2
release, and it went into a quagmare, as I lacked some background to
understand the way release are to be generated. See this effort as a
clarification usefull for any committers who will be in charge of
cutting a release in the near future :)

--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com