directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Date Wed, 26 Sep 2007 22:44:42 GMT
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@apache.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 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
> > >
> > >
> > >
> >
> >
>
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message