Apache Directory Project - [VOTE] Applying large scale changes to 1.5.x branch (trunk)

Author

[VOTE] Applying large scale changes to 1.5.x branch (trunk)

Alex Karasulu

2007-09-25, 7:11 pm

Hi all,

Looks like we have a few people talking about the pro's and con's of how to
go about making large
scale changes to the server which could effect users and our documentation
effort around user guides
etc. We have two options for this vote and some explanation is given about
each option along with it's
pros and cons so you can better evaluate an option.

[ ] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone
and embedding users.
[ ] Option #2: Create separate branch (2.5) for these kinds of changes while
trying to release a 2.0 sooner
without a major impact to the user base.
[ ] Undecided.

Pro's and Con's of options listed below. Perhaps others might add more but
we can just rename the
subject perhaps for that and use this thread for just counting votes.

Alex

Option #1 Pros
----------------------
Reduces work of maintaining several branches
Changes go in now rather than later which have to effect users anyway
Gets a 2.0 out quicker but not by much

Option #1 Cons
-----------------------
Delays 2.0 release marginally
Increases amount of change on documentation and the site
Forces users to change the server.xml which already happens when moving from
1.0->1.5
Contradicts our strategy for having stable and experimental branches

==========================

Option #2 Pros
-----------------------
Keeps users who are using 1.5 already happy since they have to change
relatively little to move to 2.0
Less changes to existing documentation although new documentation area will
be needed eventually
Completely free area to introduce dramatic changes (no worries about users)
Could bring features faster into server to avoid feature deadlock due to
architectural hurdles in 1.5

Option #2 Cons
----------------------
Yet another branch to manage.
Distracts developers from 1.5 work

Alex Karasulu

2007-09-25, 7:11 pm

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:

> [X] Undecided.
>

Either option is fine for me I just need a decision.

Alex

Emmanuel Lecharny

2007-09-25, 7:11 pm

Rahhhh... Not an easy choice...

It's not that much about the change we will inject into the server, but :
- the impact on our current users
- the roadmap we are trying to define.

IMHO, this kind of question arose because we don't have clear roadmaps.

Anyway :
[X] Option #2: Create separate branch (2.5) for these kinds of changes
while trying to release a 2.0 sooner without a major impact to the
user base.

because we can't delay releases for ever. We will always have
something new to add to the server. I don't like this 'never ending
story' issue : at some point, we must release.

Emmanuel

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> Either option is fine for me I just need a decision.
>
> Alex
>

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

Chris Custine

2007-09-25, 7:11 pm

[ ] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone
and embedding users.
[x] Option #2: Create separate branch (2.5) for these kinds of changes while
trying to release a 2.0 sooner
without a major impact to the user base.
[ ] Undecided.

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Hi all,
>
> Looks like we have a few people talking about the pro's and con's of how
> to go about making large
> scale changes to the server which could effect users and our documentation
> effort around user guides
> etc. We have two options for this vote and some explanation is given
> about each option along with it's
> pros and cons so you can better evaluate an option.
>
> [ ] Option #1: Continue making moderate to large scale changes in 1.5branch which effect standalone
> and embedding users.
> [ ] Option #2: Create separate branch (2.5) for these kinds of changes
> while trying to release a 2.0 sooner
> without a major impact to the user base.
> [ ] Undecided.
>
> Pro's and Con's of options listed below. Perhaps others might add more
> but we can just rename the
> subject perhaps for that and use this thread for just counting votes.
>
> Alex
>
>
>
> Option #1 Pros
> ----------------------
> Reduces work of maintaining several branches
> Changes go in now rather than later which have to effect users anyway
> Gets a 2.0 out quicker but not by much
>
> Option #1 Cons
> -----------------------
> Delays 2.0 release marginally
> Increases amount of change on documentation and the site
> Forces users to change the server.xml which already happens when moving
> from 1.0-> 1.5
> Contradicts our strategy for having stable and experimental branches
>
>
>
> ==========================
>
>
>
> Option #2 Pros
> -----------------------
> Keeps users who are using 1.5 already happy since they have to change
> relatively little to move to 2.0
> Less changes to existing documentation although new documentation area
> will be needed eventually
> Completely free area to introduce dramatic changes (no worries about
> users)
> Could bring features faster into server to avoid feature deadlock due to
> architectural hurdles in 1.5
>
> Option #2 Cons
> ----------------------
> Yet another branch to manage.
> Distracts developers from 1.5 work
>
>
>
>

Alex Karasulu

2007-09-26, 7:11 pm

I'm changing my vote here for several reasons. Perhaps I can explain
quickly here.

First and foremost David Jencks had some changes in the queue which will
induce change and
he is frustrated with having to wait. I'd rather deal with helping a couple
users than loose David
who has some great ideas that could help a lot.

I was undecisive because well others here were getting all sensitive on me
about users. This is the
experimental branch and we agreed on it in the past. So no need to change
that. We should stick
to our guns.

As far as doco we can all update what exists to reflect changes to the
server.xml and to the way the
server is embedded. The bottom line is we need to make serious changes and
there is some coupling.
When you change one thing for really the better you better fix it right. So
users are going to be impacted
by this anyways no matter what. We might as well get it over now.

I know we want an enterprise grade directory server out there soon. But
this recent roadmap
shows me that end of year is a pipe dream. We are where we are and we need
to accept that. Our aim
is to build community around software not to get everyone to use ApacheDS.
Users will come when the
community is better equipped to handle the code and evolve the server.
Looking at some of the responses
to the roadmap from ersin and even myself I think we all just want to work
on the features without being
rushed to do so. I know I have been rushing everytone most of all but it's
come back to basics time:
Let's have fun and build a damn good LDAP server together. It will be ready
for the enterprise when it is
ready.

So I plan to go hog wild on this code base fixing all the little nasties
that have built up over time. Going
medi-evil on the architecture in what is an experimental branch. Users can
keep up or just use 1.0 for
the time being.

[X] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone
and embedding users.

Excuse the vote change but I'm gaining more clarity from recent roadmap and
other conversations.

Alex

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> Either option is fine for me I just need a decision.
>
> Alex
>

David Jencks

2007-09-26, 7:11 pm

I'm having some trouble understanding exactly what this vote is about
since it pretty much relies on the undefined term "large changes".
It also seems to me to some extent a vote on changing the meaning of
the 1.5 branch from "experimental, big changes here" to "stable, no
changes here".

The suggested roadmap for 2.0 already seems to extend to several
months of work. Rather than a blanket vote on unspecified large
features I would prefer to see discussion of individual features on
their own merits. I think there is plenty of time before 2.0 to get
in significant architectural and configuration cleanup that will make
working on functional features much easier and more pleasant as well
as providing easier more intuitive server configuration for our
users. The original purpose of 1.5 as a experimental development
branch seems to me to be completely in line with this work.

These are the features I would like to work towards including, as
time allows:

- allow optional configuration using xbean-spring (DIRSERVER-984).
While allowing use of old-style server.xml this also lets users
configure the server according to a schema derived from the actual
server components. IIRC the schema generation process also generates
documentation for the configuration.

- gradually eliminate the *Configuration wrappers around server
components, starting with InterceptorConfiguration (DIRSERVER-1023).
This (at least for interceptors) isn't a giant code change but IMO
really improves the clarity of the code and makes it much easier to
change and work with.

- separate the operations of starting an embedded server from jndi.
E.g., currently you feed a StartupConfiguration into the jndi
environment and some magic happens :-). I don't have a clear idea
for the best replacement for this but one obvious possibility that
seems likely to work is to construct the running server directly in
code from the appropriate components and feed that into the jndi
environment. As we get closer perhaps a better solution will appear.

These are the things that will improve my experience of working with
apacheds code the most, so I have some hope that others will find
them valuable also.

I think I'll be able to spend a fair amount of time on these in the
next few weeks and based on the work I've done so far I don't think
any of this will be difficult or interfere much with development of
functional features.

Since however this vote has been called I will participate in it
under the assumption that what I've mentioned are moderate to large
scale changes :-) I would greatly appreciate those who have voted
for #2 considering separately what their opinion of these proposed
changes is. I'd like also to point out that I've spent some time
maintaining patches for the two jira issues and the time involved in
updating patches to keep in sync with other server changes is much
much larger than that for making the original patches themselves.
Due to this I will not be able to participate in this work if it is
done on a branch.

On Sep 25, 2007, at 11:18 AM, Alex Karasulu wrote:

> Hi all,
>
> Looks like we have a few people talking about the pro's and con's
> of how to go about making large
> scale changes to the server which could effect users and our
> documentation effort around user guides
> etc. We have two options for this vote and some explanation is
> given about each option along with it's
> pros and cons so you can better evaluate an option.
>
> [ X ] Option #1: Continue making moderate to large scale changes in
> 1.5 branch which effect standalone
> and embedding users.

thanks
david jencks

> [ ] Option #2: Create separate branch (2.5) for these kinds of
> changes while trying to release a 2.0 sooner
> without a major impact to the user base.
> [ ] Undecided.
>
> Pro's and Con's of options listed below. Perhaps others might add
> more but we can just rename the
> subject perhaps for that and use this thread for just counting votes.
>
> Alex
>
>
>
> Option #1 Pros
> ----------------------
> Reduces work of maintaining several branches
> Changes go in now rather than later which have to effect users anyway
> Gets a 2.0 out quicker but not by much
>
> Option #1 Cons
> -----------------------
> Delays 2.0 release marginally
> Increases amount of change on documentation and the site
> Forces users to change the server.xml which already happens when
> moving from 1.0-> 1.5
> Contradicts our strategy for having stable and experimental branches
>
>
>
> ==========================
>
>
>
> Option #2 Pros
> -----------------------
> Keeps users who are using 1.5 already happy since they have to
> change relatively little to move to 2.0
> Less changes to existing documentation although new documentation
> area will be needed eventually
> Completely free area to introduce dramatic changes (no worries
> about users)
> Could bring features faster into server to avoid feature deadlock
> due to architectural hurdles in 1.5
>
> Option #2 Cons
> ----------------------
> Yet another branch to manage.
> Distracts developers from 1.5 work
>
>
>

Chris Custine

2007-09-26, 7:11 pm

Ok, after reading all of this I guess I need to clarify or change my vote as
well... When I was voting for #2 I was thinking about the really large
scale changes like OSGi and a new facade package for helping with embeded
scenarios and had not considered the clarification to allow a couple of
these more fine grained improvements.

I would like to see the XBean and config bean changes prior to 2.0 release,
so I will change my vote with a caveat below. These changes are really
important to the usability and flexibility in customizing and will hepl the
eventual 2.0 release have much more longevitiy than 1.0 did.

[x] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone and embedding users.

I think we can clarify this in the Roadmap that Emmanuel sent out so that it
is clear what is in 1.5.x-2.0 and what is saved for 2.5.

Thanks,
Chris

My caveat is that the
On 9/26/07, David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> I'm having some trouble understanding exactly what this vote is about
> since it pretty much relies on the undefined term "large changes".
> It also seems to me to some extent a vote on changing the meaning of
> the 1.5 branch from "experimental, big changes here" to "stable, no
> changes here".
>
> The suggested roadmap for 2.0 already seems to extend to several
> months of work. Rather than a blanket vote on unspecified large
> features I would prefer to see discussion of individual features on
> their own merits. I think there is plenty of time before 2.0 to get
> in significant architectural and configuration cleanup that will make
> working on functional features much easier and more pleasant as well
> as providing easier more intuitive server configuration for our
> users. The original purpose of 1.5 as a experimental development
> branch seems to me to be completely in line with this work.
>
> These are the features I would like to work towards including, as
> time allows:
>
> - allow optional configuration using xbean-spring (DIRSERVER-984).
> While allowing use of old-style server.xml this also lets users
> configure the server according to a schema derived from the actual
> server components. IIRC the schema generation process also generates
> documentation for the configuration.
>
> - gradually eliminate the *Configuration wrappers around server
> components, starting with InterceptorConfiguration (DIRSERVER-1023).
> This (at least for interceptors) isn't a giant code change but IMO
> really improves the clarity of the code and makes it much easier to
> change and work with.
>
> - separate the operations of starting an embedded server from jndi.
> E.g., currently you feed a StartupConfiguration into the jndi
> environment and some magic happens :-). I don't have a clear idea
> for the best replacement for this but one obvious possibility that
> seems likely to work is to construct the running server directly in
> code from the appropriate components and feed that into the jndi
> environment. As we get closer perhaps a better solution will appear.
>
> These are the things that will improve my experience of working with
> apacheds code the most, so I have some hope that others will find
> them valuable also.
>
> I think I'll be able to spend a fair amount of time on these in the
> next few weeks and based on the work I've done so far I don't think
> any of this will be difficult or interfere much with development of
> functional features.
>
> Since however this vote has been called I will participate in it
> under the assumption that what I've mentioned are moderate to large
> scale changes :-) I would greatly appreciate those who have voted
> for #2 considering separately what their opinion of these proposed
> changes is. I'd like also to point out that I've spent some time
> maintaining patches for the two jira issues and the time involved in
> updating patches to keep in sync with other server changes is much
> much larger than that for making the original patches themselves.
> Due to this I will not be able to participate in this work if it is
> done on a branch.
>
> On Sep 25, 2007, at 11:18 AM, Alex Karasulu wrote:
>
>
> thanks
> david jencks
>
>
>

Emmanuel Lecharny

2007-09-26, 7:11 pm

Hi,

as soon as we have a clear roadmap for 2.0, the vote will be useless.
I agree with David and Chris on that.

The main problem is to define the roadmap, and to stick to it.
Whatever time it takes to cut the 2.0 release (being 3 months or 6
months), I think we need to freeze the features we want in it, or we
will face what I call the "Not Good Enough For Release syndroma"...

On 9/27/07, Chris Custine <ccustine-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> Ok, after reading all of this I guess I need to clarify or change my vote=
as
> well... When I was voting for #2 I was thinking about the really large
> scale changes like OSGi and a new facade package for helping with embeded
> scenarios and had not considered the clarification to allow a couple of
> these more fine grained improvements.
>
> I would like to see the XBean and config bean changes prior to 2.0 releas=
e,
> so I will change my vote with a caveat below. These changes are really
> important to the usability and flexibility in customizing and will hepl t=
he
> eventual 2.0 release have much more longevitiy than 1.0 did.
>
> [x] Option #1: Continue making moderate to large scale changes in 1.5 bra=
nch
> which effect standalone and embedding users.
>
> I think we can clarify this in the Roadmap that Emmanuel sent out so that=
it
> is clear what is in 1.5.x-2.0 and what is saved for 2.5.
>
> Thanks,
> Chris
>
> My caveat is that the
>
> On 9/26/07, David Jencks < david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
=3D=3D=3D[vbcol=seagreen]
>
>

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

Stefan Zoerner

2007-09-27, 7:12 pm

Alex Karasulu wrote:

> [X] Option #1: Continue making moderate to large scale changes in 1.5
> branch which effect standalone
> and embedding users.
> [ ] Option #2: Create separate branch (2.5) for these kinds of changes
> while trying to release a 2.0 sooner
> without a major impact to the user base.
> [ ] Undecided.

Greetings from Hamburg,
Stefan

---8<---

Stefan Zoerner (szoerner-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org)
Committer :: PMC Member

Apache Directory Project
http://directory.apache.org