Apache Directory Project - [ApacheDS] Ramifications of removing configuration beans

Author

[ApacheDS] Ramifications of removing configuration beans

Alex Karasulu

2007-09-25, 1:11 pm

Hi all,

Chris Custine and David Jencks have been advising the removal of the
configuration beans to
directly wire up components in the server. I think they're right after
seeing just how many problems
the present configuration bean setup causes. Also this will not happen
immediately if it does in
one shot. The progression will be gradual.

However doing this has a huge impact and I want everyone to be aware of
them. First and foremost
the way users embed the server will change. The server.xml file will
completely change as well so
this may disappoint our users who have been using 1.5.x releases since they
are more stable than
1.0.x even though 1.5.x is labeled as experimental.

So it is obvious from a technical standpoint that this must be done. The
remaining question is when.
Should we just get 2.0 out ASAP so users have something and start
immediately on a 2.5? So this
is a question that our users and team must answer. If yes then we need to
figure out what to stuff
into 2.0 before it goes out. We can even start 2.5 in a separate branch
before 2.0 is out the door if
people want to just go hog wild with these changes yet brace our users from
them.

Thoughts?

Alex

Ersin Er

2007-09-25, 1:11 pm

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Hi all,
>
> Chris Custine and David Jencks have been advising the removal of the
> configuration beans to
> directly wire up components in the server. I think they're right after
> seeing just how many problems
> the present configuration bean setup causes. Also this will not happen
> immediately if it does in
> one shot. The progression will be gradual.
>
> However doing this has a huge impact and I want everyone to be aware of
> them. First and foremost
> the way users embed the server will change. The server.xml file will
> completely change as well so
> this may disappoint our users who have been using 1.5.x releases since
> they are more stable than
> 1.0.x even though 1.5.x is labeled as experimental.
>
> So it is obvious from a technical standpoint that this must be done. The
> remaining question is when.
> Should we just get 2.0 out ASAP so users have something and start
> immediately on a 2.5? So this
> is a question that our users and team must answer. If yes then we need to
> figure out what to stuff
> into 2.0 before it goes out. We can even start 2.5 in a separate branch
> before 2.0 is out the door if
> people want to just go hog wild with these changes yet brace our users
> from them.

I dislike the idea of maintaining three different branches of the server. I
suggest making this change before releasing 2.0 and writing a complete
"what's changed?" guide.

Thoughts?
>
> Alex
>
>
>
>
>

--
Ersin Er
http://www.ersin-er.name

Alex Karasulu

2007-09-25, 1:11 pm

Yep this is an option too. Emmanuel has some ideas as well such as writing
translators from old server.xml to
new one. But I'm not keen on this.

Our problem is we are treating 1.5 branch as if it were a stable branch and
not using it for hard core experimental
work anymore since we're driving users towards it since it just blows
1.0away. This puts us into the dilemma of
dealing with the woes of users.

I guess we can just say hey this is an experimental branch that you have to
deal with changes to. WDYT?

Alex

On 9/25/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> I dislike the idea of maintaining three different branches of the server.
> I suggest making this change before releasing 2.0 and writing a complete
> "what's changed?" guide.
>
> Thoughts?
>
>
> --
> Ersin Er
> http://www.ersin-er.name

Emmanuel Lecharny

2007-09-25, 1:11 pm

My POV is a little more inclining toward users than experimentations.

I would agree with what Ersin said : if we have to do it, do it before 2.0.

Remember that we will have to provide migration tools for 1.0 -> 2.0
version anyway, data and conf, so if we change the conf only once, we
will save us some energy.

Consider also that we may move to OSGi, so if we inject the new conf
in 2.0, we will have another conf for 3.0 ! I don't see how possibly
we can inject a OSGi compatible conf into 2.0...

For those reasons, I would say : keep 2.0 conf as is, and do
experimentations in a branch.

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> Yep this is an option too. Emmanuel has some ideas as well such as writi=
ng
> translators from old server.xml to
> new one. But I'm not keen on this.
>
> Our problem is we are treating 1.5 branch as if it were a stable branch a=
nd
> not using it for hard core experimental
> work anymore since we're driving users towards it since it just blows 1.0
> away. This puts us into the dilemma of
> dealing with the woes of users.
>
> I guess we can just say hey this is an experimental branch that you have =
to
> deal with changes to. WDYT?
>
> Alex
>
>
> On 9/25/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> configuration beans to
er[vbcol=seagreen]
> seeing just how many problems
en[vbcol=seagreen]
> immediately if it does in
of[vbcol=seagreen]
> them. First and foremost
> completely change as well so
e[vbcol=seagreen]
> they are more stable than
> The remaining question is when.
> immediately on a 2.5? So this
ed[vbcol=seagreen]
> to figure out what to stuff
nch[vbcol=seagreen]
> before 2.0 is out the door if
s[vbcol=seagreen]
> from them.
r.[vbcol=seagreen]
> I suggest making this change before releasing 2.0 and writing a complete
> "what's changed?" guide.
>
>

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

Alex Karasulu

2007-09-25, 1:11 pm

On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> For those reasons, I would say : keep 2.0 conf as is, and do
> experimentations in a branch.

So we're not going to be too free to experiment from now on in 1.5 branch?
This sort of
breaks with our general policy on branches yet it's appealing in many other
ways. It's
just a matter of trade offs. It's more important in this case for us to
just make a decision.

Either option is fine with me since both choices take relatively the same
time and energy.
I started this thread to see what people are thinking about it and it sounds
as though there
is a split. Perhaps we just need a vote and go with it.

Alex

Chris Custine

2007-09-25, 7:11 pm

See, this is something that I have never liked about the stable / unstable
release categorization... How can we ever claim to have a stable
2.0release without some limitation of changes on the unstable
1.5 at some point?

My preference is to begin limiting major changes to 1.5.x for the sake of
stabilizing it to be the 2.0 stable release, and at that point we EOL 1.0.
We start the major refactorings in 2.5 based on the 2.0 or a late
1.5release. I think anything else is just too complicated for us to
manage
properly.

Thanks,
Chris

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> So we're not going to be too free to experiment from now on in 1.5branch? This sort of
> breaks with our general policy on branches yet it's appealing in many
> other ways. It's
> just a matter of trade offs. It's more important in this case for us to
> just make a decision.
>
> Either option is fine with me since both choices take relatively the same
> time and energy.
> I started this thread to see what people are thinking about it and it
> sounds as though there
> is a split. Perhaps we just need a vote and go with it.
>
> Alex
>
>

Alex Karasulu

2007-09-25, 7:11 pm

On 9/25/07, Chris Custine <ccustine-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> See, this is something that I have never liked about the stable / unstable
> release categorization... How can we ever claim to have a stable 2.0release without some limitation of changes on the unstable
> 1.5 at some point?

Yes this is rigid but sometimes for good reasons for server products. But I
can debate this with my self all day long. I too have your concerns. I just
don't have a better option right now. I know now is not the time to rehash
this topic again since you did not seem to want to but perhaps we can reopen
this conversation again. There's got to be a better way out there. We'll
find it probably.

My preference is to begin limiting major changes to 1.5.x for the sake of
> stabilizing it to be the 2.0 stable release, and at that point we EOL 1.0.
> We start the major refactorings in 2.5 based on the 2.0 or a late 1.5release. I think anything else is just too complicated for us to manage
> properly.
>

Thanks for the feedback. I kicked off a vote on this.

Alex

Emmanuel Lecharny

2007-09-25, 7:11 pm

I didn't say that we should not experiment in branch, but that we
should not merge the branch in 2.0, otherwise we will have too many
configuration change.

When 2.0 will be out, we may then merge the branch with trunk, or
discard the branch.

Branching to experiment this new configuration is like if we
anticipate the 2.5 trunk, and I have nothing againt that.

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> So we're not going to be too free to experiment from now on in 1.5 branch=
?
> This sort of
> breaks with our general policy on branches yet it's appealing in many oth=
er
> ways. It's
> just a matter of trade offs. It's more important in this case for us to
> just make a decision.
>
> Either option is fine with me since both choices take relatively the same
> time and energy.
> I started this thread to see what people are thinking about it and it sou=
nds
> as though there
> is a split. Perhaps we just need a vote and go with it.
>
> Alex
>
>

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

Ersin Er

2007-09-25, 7:11 pm

We need a Release Schedule/Roadmap for 2.0 right now.

On 9/25/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> I didn't say that we should not experiment in branch, but that we
> should not merge the branch in 2.0, otherwise we will have too many
> configuration change.
>
> When 2.0 will be out, we may then merge the branch with trunk, or
> discard the branch.
>
> Branching to experiment this new configuration is like if we
> anticipate the 2.5 trunk, and I have nothing againt that.
>
> On 9/25/07, Alex Karasulu <akarasulu@apache.org> wrote:
> other
> same
> sounds
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

--
Ersin Er
http://www.ersin-er.name

Emmanuel Lecharny

2007-09-25, 7:11 pm

ok

I will try to push it on the list, gathering the spare informations we
have all over. this will be a draft, anyone of us can push some ideas
of features.

On 9/25/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> We need a Release Schedule/Roadmap for 2.0 right now.
>
>
> On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> branch?
> other
to[vbcol=seagreen]
> same
> sounds
>
>
>
> --
>
> Ersin Er
> http://www.ersin-er.name

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

Niclas Hedhman

2007-09-27, 1:11 am

On Wednesday 26 September 2007 00:58, Alex Karasulu wrote:

One way that has worked for me in product development in the past is;

1. Make the TRUNK the experimental branch, or at least where the stuff you
think(!) will end up in the product will take shape.

2. Bug fixes are made in branches off the release tags, and in effect are
very limited in time. Each fix is also ported straight into TRUNK, when
appropriate.

3. Make releases very often for bug fixes, i.e. immediately after fix.

4. Avoid disruptive changes. This is sometimes difficult, but it makes life a
lot easier. The suggested change is disruptive, but the benefits may overcome
the cost. My approach would be to create a runtime compatibility layer first,
and use "on-the-fly" transformation to new formats.

By tugging along such setup, you only have a "latest released" and "current
development" to worry about.
Modularity also allows for smaller pieces to be released independently, as
long as inter-modular interfaces remain stable. This can also help users a
lot to be fairly close to bleeding-edge, without compiling the TRUNK with
possibility of failures and such.

Cheers
--
Niclas Hedhman, Software Developer

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug