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.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to