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 <[EMAIL PROTECTED]> 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 < [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 > > > > > > > > > > > > > > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
