You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/09/25 20:18:29 UTC
[VOTE] Applying large scale changes to 1.5.x branch (trunk)
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.
[ ] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone
and embedding users.
[ ] 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
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Alex Karasulu <ak...@apache.org>.
I'm changing my vote here for several reasons. Perhaps I can explain
quickly here.
First and foremost David Jencks had some changes in the queue which will
induce change and
he is frustrated with having to wait. I'd rather deal with helping a couple
users than loose David
who has some great ideas that could help a lot.
I was undecisive because well others here were getting all sensitive on me
about users. This is the
experimental branch and we agreed on it in the past. So no need to change
that. We should stick
to our guns.
As far as doco we can all update what exists to reflect changes to the
server.xml and to the way the
server is embedded. The bottom line is we need to make serious changes and
there is some coupling.
When you change one thing for really the better you better fix it right. So
users are going to be impacted
by this anyways no matter what. We might as well get it over now.
I know we want an enterprise grade directory server out there soon. But
this recent roadmap
shows me that end of year is a pipe dream. We are where we are and we need
to accept that. Our aim
is to build community around software not to get everyone to use ApacheDS.
Users will come when the
community is better equipped to handle the code and evolve the server.
Looking at some of the responses
to the roadmap from ersin and even myself I think we all just want to work
on the features without being
rushed to do so. I know I have been rushing everytone most of all but it's
come back to basics time:
Let's have fun and build a damn good LDAP server together. It will be ready
for the enterprise when it is
ready.
So I plan to go hog wild on this code base fixing all the little nasties
that have built up over time. Going
medi-evil on the architecture in what is an experimental branch. Users can
keep up or just use 1.0 for
the time being.
[X] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone
and embedding users.
Excuse the vote change but I'm gaining more clarity from recent roadmap and
other conversations.
Alex
On 9/25/07, Alex Karasulu <ak...@apache.org> wrote:
>
> On 9/25/07, Alex Karasulu <ak...@apache.org> wrote:
>
> > [X] Undecided.
> >
>
> Either option is fine for me I just need a decision.
>
> Alex
>
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Rahhhh... Not an easy choice...
It's not that much about the change we will inject into the server, but :
- the impact on our current users
- the roadmap we are trying to define.
IMHO, this kind of question arose because we don't have clear roadmaps.
Anyway :
[X] 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.
because we can't delay releases for ever. We will always have
something new to add to the server. I don't like this 'never ending
story' issue : at some point, we must release.
Emmanuel
On 9/25/07, Alex Karasulu <ak...@apache.org> wrote:
> On 9/25/07, Alex Karasulu <ak...@apache.org> wrote:
>
> > [X] Undecided.
> >
>
> Either option is fine for me I just need a decision.
>
> Alex
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Alex Karasulu <ak...@apache.org>.
On 9/25/07, Alex Karasulu <ak...@apache.org> wrote:
> [X] Undecided.
>
Either option is fine for me I just need a decision.
Alex
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <cc...@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
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Chris Custine <cc...@apache.org>.
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 <da...@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
> >
> >
> >
>
>
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by David Jencks <da...@yahoo.com>.
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
>
>
>
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Stefan Zoerner <sz...@apache.org>.
Alex Karasulu wrote:
> [X] Option #1: Continue making moderate to large scale changes in 1.5
> branch which effect standalone
> and embedding users.
> [ ] 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.
Greetings from Hamburg,
Stefan
---8<---
Stefan Zoerner (szoerner@apache.org)
Committer :: PMC Member
Apache Directory Project
http://directory.apache.org
Re: [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Chris Custine <cc...@apache.org>.
[ ] Option #1: Continue making moderate to large scale changes in 1.5 branch
which effect standalone
and embedding users.
[x] 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.
On 9/25/07, Alex Karasulu <ak...@apache.org> 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.
>
> [ ] Option #1: Continue making moderate to large scale changes in 1.5branch which effect standalone
> and embedding users.
> [ ] 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
>
>
>
>
Re: [RESULTS] [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Emmanuel Lecharny <el...@gmail.com>.
I voted for small changes, but as we won't be able to get a 2.0 out
for december anyway, I would prefer have some major refactoring right
now. We are suffering from some major drawbacks we should get rid of.
You bought my vote !
+1
On 9/29/07, Alex Karasulu <ak...@apache.org> wrote:
> We officially closed this vote at 2pm EST.
>
> Here are the votes for applying large scale changes:
>
> Chris Custine
> Alex Karasulu
> Stefan Zoerner
> David Jencks (non-binding)
>
> Although Emmanuel voted for not having large scale changes I think he
> changed his mind at some
> point in other threads seeing how hard it would be to deliver the roadmap
> for 2.0 by December.
> However instead of putting words in your mouth Emmanuel I'll just count you
> as opposed to large
> changes.
>
> This was a tough vote. I myself was undecided for a while. We're trying
> to get stable products out
> with the features our users need of them and that's a great thing. However
> sometimes the size and
> scope just don't give us the ability to pull of the task in the time
> alloted. Who said it's easy to build
> an LDAP server and since we're the first Java LDAP server that makes it even
> harder.
>
> Let's do it right and shoot for a release before Apache Conference Europe
> next year. Then we're have
> something big to talk about.
>
> This vote does not solve our problems though. We still have to define the
> roadmap and agree to it
> and find someone to keep us honest making sure that we make our dates. So
> this is just a realization
> and not the solution to our problems.
>
> Personally I'm pretty excited because now we have some juicy problems to
> confront and no more excuses
> to put them off since we now have the freedom to aggressively confront
> them..
>
> Let's do it!!!
>
> Alex
>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
[RESULTS] [VOTE] Applying large scale changes to 1.5.x branch (trunk)
Posted by Alex Karasulu <ak...@apache.org>.
We officially closed this vote at 2pm EST.
Here are the votes for applying large scale changes:
Chris Custine
Alex Karasulu
Stefan Zoerner
David Jencks (non-binding)
Although Emmanuel voted for not having large scale changes I think he
changed his mind at some
point in other threads seeing how hard it would be to deliver the roadmap
for 2.0 by December.
However instead of putting words in your mouth Emmanuel I'll just count you
as opposed to large
changes.
This was a tough vote. I myself was undecided for a while. We're trying to
get stable products out
with the features our users need of them and that's a great thing. However
sometimes the size and
scope just don't give us the ability to pull of the task in the time
alloted. Who said it's easy to build
an LDAP server and since we're the first Java LDAP server that makes it even
harder.
Let's do it right and shoot for a release before Apache Conference Europe
next year. Then we're have
something big to talk about.
This vote does not solve our problems though. We still have to define the
roadmap and agree to it
and find someone to keep us honest making sure that we make our dates. So
this is just a realization
and not the solution to our problems.
Personally I'm pretty excited because now we have some juicy problems to
confront and no more excuses
to put them off since we now have the freedom to aggressively confront
them..
Let's do it!!!
Alex