directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <ccust...@apache.org>
Subject Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Date Wed, 26 Sep 2007 22:04:21 GMT
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@yahoo.com> 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:
>
> > 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
> >
> >
> >
>
>

Mime
View raw message