directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [ApacheDS] Big Bang Cleanup
Date Sat, 29 Sep 2007 10:34:09 GMT
Hi guys,

a new branch has been created where we are supposed to introduce some
major modifications and new features. That's fine. However, I would
like everyone to be aware of some traps we should not fell in :

1) We currently have a live trunk, which will be used to release a
1.5.2 release sooner or later (a bug fix release). We have to find a
way to merge changes from the trunk to the branch _or_ from the branch
to the trunk without jeopardize the trunk

2) Even if this new branch is just a branch, at some point we may ask
ourselves if this will become the new trunk for a 2.0 (ie, will we
abandon the current trunk or not)

3) Our number of committers is big : we are more than 10, and at least
5 of us are directly working on the server. If we start pouring some
new features and doing some big modifications, we will have to
document what we are doing, and to share the information

I would like to be a little bit more precise about point (3) :
- we can have big spreaded modifications, like switching from
String/byte[] to Value
- or we can have local modification (even if they are big : like XmlBeans).

the second kind of modification can be done quite easily, but the
first kind of modification should also be done in seperate branches,
otherwise the server will become a big f*** mess quickly.

Also keep in mind that we have a roadmap, so try to stick to it : a
modification can be tagged as a JIRA fix (we just have to inject some
new JIRA, probably prefixing them with a tag like [bigbang]), making
it easier to see the consequences of a modification.

The documentation is absolutely necessary, as some of us have a deep
knowledge about the server internals, but this is not a general case.
If we introduce deep modifications without documentation, then
- people who had some knowledge about the server will lose it
- and you won't be able to share your vision, leading to some
potential bad choices.

In three words : share your vision ! Confluence Is The Way, Mailing
List Is The Messenger !

I don't want to scare you all, but we must be careful. We are not
anymore in the ancient ages of ADS where 2 or 3 persons were working
in caves with stones and wood drafting the 1.0 release... Let's try to
cut this 2.0 in a way all of our committers can jump into the common
work (I'm also thinking about Studio, which will be impacted by this
effort, and about our doc writers, which will have to understand what
are the new features about without having to crawl into the code).

Last, not least, keep in mind we are targetting VSLDAP compliance for this 2.0.

Yes, yes, I know, it's not funny... But this is a live project !


Emmanuel L├ęcharny

View raw message