directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS] Big Bang Cleanup
Date Sat, 29 Sep 2007 17:00:51 GMT
Morning all,

On 9/29/07, Emmanuel Lecharny <> wrote:
> 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).

Emmanuel this is slighly incorrect perhaps in terminology according to our
release scheme and
policy which you had a hand in establishing.  Let me try to explain below
with a review of what
we voted on.

Oh 1.5.2 is a feature release not a bug fix release however we can do bug
fixes in these releases
as we get feedback.

Our model is simple.

1). Start an experimental branch as the main branch of development (x.5branch)
2). Add new features and do some "feature releases" for early access to
these features i.e. x=1
     - 1.5.0
     - 1.5.1
     - 1.5.2
3). Feature Freeze: freeze the addition of new features to begin to cleanup
and stabilize
4). Release next major release candidates (x+1).0.0-RCy suffix with bug
fixes only ie.:
     - 2.0.0-RC1
     - 2.0.0-RC2
     - 2.0.0-RC3
5). Release final major version i.e. 2.0.0
6). Copy this branch into branches area as 2.0 branch and do "bug fix"
(ONLY) releases
7). Designate trunk as new experimental branch in this example 2.5 with next
feature release 2.5.0 etc ...

So the cycle continues.  Right now a feature freeze has not been called.
But I do agree at some point
very soon we have call it.  So my focus for the time being is not on bugs
although I will fix them for sure
when I can without taking too much time.

Please take my comments below as constructive criticism: I have profound
respect for you so I don't
want you to take these comments the wrong way.

Emmanuel what I find you always doing is mixing concepts.  You mix features
and bug fix releases.
I feel like you're mixing some things perhaps we did not have enough
discussion.  Let me give you an
example: a while back you worked on the 1.0 branch where you changed
something freely without it
being needed to fix a bug.  As a result you changed the classes serialized
into the partition entries and
this made it so 1.0.1 partitions were not compatible with 1.0.2 partitions.
I'm pointing this out because
now you're doing just the opposite with experimental releases.  Here we
should have the freedom to
change as much as we like so don't hold back.  This is the time to be
liberal not after the final major
release in bug fix branches.

We have to stick to what we decided and be firm about it or everything false
apart.  You're a very valuable
part of this project but I need your help on this or we're just going to
fall apart making policies and not adhering
to them.  Basically we're going to be spinning cycles without producing

We have already started doing that by not adhering to our release management

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

Oh certainly I agree.

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)

We can swap out the existing trunk for this bigbang branch or just merge
back but I guess this depends on our strategy.

It might be best for some weeks to just have us make the large changes we
need for now in this common area together
the be done with this in 2-4 weeks.  Then we continue back in the trunk with
feature releases until we vote to freeze the
feature additions and start releasing RCs.

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


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.



View raw message