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
