directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [VOTE] Policy for Managing TLP POM
Date Wed, 23 May 2007 15:35:42 GMT
After my clarifications on IRC about this stuff do you want to reconsider
your vote?

On 5/23/07, Emmanuel Lecharny <> wrote:
> 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
>, 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 :)
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message