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 <[EMAIL PROTECTED]> 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 > > > > > > > >
