Release plan for 3.3 ( first draft )

[cm...@yahoo.com]

Hi,

I checked in the initial draft of the "release plan for 3.3" proposal:
http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/RELEASE-PLAN-3.3

I'll publish the final version and propose it for vote after any concerns 
are addressed and at least 3 commiters will volunteer to help making it
happen. All votes are important - but in order for this to happen at least
3 commiters should vote +1.  

Anyone can volunteer to help - with bug fixing, comments on the code,
bug reports, running the tests on different platforms, building and running it 
in different environments.

The proposed Tomcat 3.3 will not have any new major functionality compared
with tomcat 3.2. Most of the work has been put in finishing up the 
modularization and reorganization of code, plus a significant  increase 
in performance. Most of the changes that would have delayed 3.2 are also
included in 3.3.


Costin

Re: Release plan for 3.3 ( first draft )

[Hans Bergsten <ha...@gefionsoftware.com>]

cmanolache@yahoo.com wrote:
> 
> Hi,
> 
> I checked in the initial draft of the "release plan for 3.3" proposal:
> http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/RELEASE-PLAN-3.3

I have some comments, see below.

> I'll publish the final version and propose it for vote after any concerns
> are addressed and at least 3 commiters will volunteer to help making it
> happen. All votes are important - but in order for this to happen at least
> 3 commiters should vote +1.

Before you put the proposal up to a vote, we need to make sure we all
agree on the voting rules (they will be clarified as decided by PMC,
and I suggest that this work is started on the general list).

The rules for voting on the actual release are already clearly
defined in our guidelines <http://jakarta.apache.org/site/decisions.html>):

  Release Testing

  After a new release is built, it must be tested before being released 
  to the public. Majority approval is required before the release can be 
  made. 

Majority approval is defined in the same document as:

  An action requiring majority approval must receive at least 3 
  binding +1 votes and more +1 votes than -1 votes. 

A "binding vote" is a vote by a Committer, as opposed to a Developer.

What's not crystal clear is how to deal with votes on the release
proposal. The closest thing I can find is this:

  Release Plan

  A release plan is used to keep all Developers aware of when a release 
  is desired, who will be the release manager, when the repository will 
  be frozen to create a release, and other assorted information to keep 
  Developers from tripping over each other. Lazy majority decides each 
  issue in a release plan. 

In the section describing the different types of votes, it says this
about "lazy approval": "All other action items are considered to have lazy 
approval until somebody votes -1, after which point they are decided by 
either consensus or majority vote, depending on the type of action item."

I take this to mean that each item in the release plan can be get a -1
vote. If the item can not be changed in such a way that the -1 voter
is willing to drop his/her -1, or can not be convinced to do so without
change, the issue must be resolved by consensus or majority vote.
The term "lazy majority" seem to imply that this calls for a majority
vote, but I'd like to see this confirmed and/or clarified.

I also take it, based on the existing guidelines, that a +1 on the
release plan implies a commitment to actively help with the implementation,
and a +1 on the release proposal implies a commitment to actively
support the released product (fix bugs, answer user questions, etc.).

I will start a thread about this on the General list so we can get
it resolved ASAP.

> [...]

Some feedback on the actual release plan follows:

One thing I mentioned in the meeting as being very important for
the release plan is to describe exactly what will be implemented 
in the new release. I don't see that in this first draft.

Reading our guidelines, I suggest you create/update the STATUS
document so that it contains all items that the new release will
cover, both things that you have already done since 3.2 and things
you plan to do before the release. Then refer to these items in
the Goals section of the release plan, and list per milestone
which items should be taken care of for that milestone. The things
you list in the current Goal section looks more like release
criteria to me.

Another important part, that I'm sure you're aware of, is that
a release manager must be appointed and named in the plan before
you can put it up for a vote.

I agree with Jon that you should not say that no major development
will be done after this release; that all depends on what happens
after it's released. If major changes are needed, they can be done
following the same procedure, i.e. an approved release plan followed
by an approved release proposal.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com