Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=VM7bUsfRPExI4sYDKSBB8MVXdW2dzL+YI+UrhPehEjP83TDpmRt4zebx3BCOqTW31DvHsmH4eX/NPLpw7Ndmo1+vnz8r6Hiyet/Lv/Snkg68GAuPIUr1YcgblqllQQ2Zj722gtnqK7vs/EzWTJOZD+CoC/DKydW4JWOEoFppioE=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <a32f6b020709251118n376783e6sd191740b71ec33b3@mail.gmail.com>
References: <a32f6b020709251118n376783e6sd191740b71ec33b3@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1A0EC90C-185A-4E87-8457-F656107E2080@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Date: Wed, 26 Sep 2007 12:00:33 -0700
To: "Apache Directory Developers List" <dev@directory.apache.org>

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
>
>
>