You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by John Holman <j....@qmw.ac.uk> on 2001/01/18 12:33:27 UTC
Proposed release of 3.3
I'm a user and I rightly don't get a vote (and might do better to keep quiet!) but I think releasing a version 3.3 would be bad for the project unless the concerns about support can be fully resolved. This is so even though it seems to be agreed that the basic code itself is technically superior to 3.2 (cleaner and more maintainable, better performance etc) and even if the new bugs it introduces are fixed.
The danger, it seems to me, is that many of those actively supporting 3.2 at the moment would prefer the project to move on to 4.x and will not be keen on supporting a 3.3, while those wanting a version 3.3 are focussed more upon program design and writing new code than bug fixes and user support. Releasing a 3.3 will inevitably cause some users who would otherwise have moved on to 4.x to adopt it believing it to be the most "stable" version. But if it isn't properly supported, that will be far from the case, and will cause problems for users and the project alike.
John.
Re: Proposed release of 3.3
Posted by cm...@yahoo.com.
> At 12:30 18/1/01 -0800, cmanolache@yahoo.com wrote:
> >2. It seems he made a distinction between +1 ( I support the plan or
> >release ) and "commited" +1 ( I support the plan _and_ I commit to help).
>
> I understood the first case to be a +0 - ie nice idea but I ain't gonna put
> any effort into maintaining it. As opoosed to -0 which was bad idea but I
> don't feel need to veto it ;)
It makes sense :-). Thanks for clarifying, you are right.
--
Costin
Re: Proposed release of 3.3
Posted by Peter Donald <do...@apache.org>.
At 12:30 18/1/01 -0800, cmanolache@yahoo.com wrote:
>2. It seems he made a distinction between +1 ( I support the plan or
>release ) and "commited" +1 ( I support the plan _and_ I commit to help).
I understood the first case to be a +0 - ie nice idea but I ain't gonna put
any effort into maintaining it. As opoosed to -0 which was bad idea but I
don't feel need to veto it ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Proposed release of 3.3
Posted by James Duncan Davidson <du...@x180.net>.
On 1/18/01 12:30 PM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
> 2. It seems he made a distinction between +1 ( I support the plan or
> release ) and "commited" +1 ( I support the plan _and_ I commit to help).
>
> 3. My vote will be a "commited" +1.
My reading of the situation is that if you vote +1, that's a commitment to
help, not just support of the plan. Support of the plan is a +0.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Proposed release of 3.3
Posted by cm...@yahoo.com.
> My personal feeling about this as a Jakarta (but not Tomcat) Committer
> is that the requirement for three binding (+1) votes before a public
> release is there to address the support issues. A (+1) vote on a public
> release should mean that you are signing-on for future development and
> support. In this particular context, Costin himself might only vote
> (+0) -- if he plans to only remain active outside Jakarta (developing
> facades and what-not). So at least three * other * Committers would
> need to sign-on with a (+1) before it "shipped".
I must clarify my understanding of the voting process ( or at least what
Brian and Roy described ):
1. The release proposal ( not the plan ) needs majority aproval, with
at least 3 "commited" +1s.
2. It seems he made a distinction between +1 ( I support the plan or
release ) and "commited" +1 ( I support the plan _and_ I commit to help).
3. My vote will be a "commited" +1.
I'm not sure what was the rule for a "release plan", but I suppose the
rules should be identical as for the final "release proposal".
In addition, I don't think a +1 vote on the release plan implys a +1 vote
on the final release - the plan is just a plan, and the "release
proposal" vote will be based on the plan execution.
I wouldn't mind to use the name "proposed 3.3" during plan execution,
meaning that the final name "3.3" will be used only after the _release_
itself is voted.
( I'll incorporate all the feedback I got during evening time, the lunch
brake is too short for that :-)
--
Costin
Re: Proposed release of 3.3
Posted by Ted Husted <ne...@husted.com>.
My personal feeling about this as a Jakarta (but not Tomcat) Committer
is that the requirement for three binding (+1) votes before a public
release is there to address the support issues. A (+1) vote on a public
release should mean that you are signing-on for future development and
support. In this particular context, Costin himself might only vote
(+0) -- if he plans to only remain active outside Jakarta (developing
facades and what-not). So at least three * other * Committers would
need to sign-on with a (+1) before it "shipped".
Most of the end-user support is (or should be) handled by the end-users
on the user list. Here again, meritocracy will balance out, since the
better release will attract the most power users, who will support the
newbies, generate the most traffic on the user-list, and thereby
attract more newbies, and increase the user-base.
Anyone who didn't vote (+1) on a public release, and doesn't want to
support that release, shouldn't. Anyone who is supporting any version
of any Jakarta project should do so on the public list, where all will
benefit.
- Ted, practicing what I preach at < http://husted.com/about/struts >.
*********** REPLY SEPARATOR ***********
On 1/18/2001 at 11:33 AM John Holman wrote:
I'm a user and I rightly don't get a vote (and might do better to keep
quiet!) but I think releasing a version 3.3 would be bad for the
project unless the concerns about support can be fully resolved. This
is so even though it seems to be agreed that the basic code itself is
technically superior to 3.2 (cleaner and more maintainable, better
performance etc) and even if the new bugs it introduces are fixed.
The danger, it seems to me, is that many of those actively supporting
3.2 at the moment would prefer the project to move on to 4.x and will
not be keen on supporting a 3.3, while those wanting a version 3.3 are
focussed more upon program design and writing new code than bug fixes
and user support. Releasing a 3.3 will inevitably cause some users who
would otherwise have moved on to 4.x to adopt it believing it to be the
most "stable" version. But if it isn't properly supported, that will be
far from the case, and will cause problems for users and the project
alike.
John.