Certainly. There might be something missing, but this is my first shot:

- Keep CVS up to date (tagging on releases, maybe create a branch for a release cycle, etc.)
- Keeping contact with users, contributors and committers and communicates with Apache release people
- Seeing to general documentation being up to date
- Running tests or at least see to them buing run (if possible without failure)
- Preparing the release (have votes, write or prepare release notes)
- Finally: Have a look at http://wiki.apache.org/jakarta-slide/BuildSignUploadDeploy


How long will it take you? Hard to say, apart from particiapting in the project which really is a must for a release manager the last milestone release took me an afternoon of work. However, a full release cycle with beta(s), rc(s) and a final release will *definitely* take more time.

The 2.0 release certainly can not be used to estimate anything as tremendous amounts of work went to cleaning up everything and creating distribution procedures.

Cheers,
Oliver

Jacob Lund wrote:

Hi Oliver!

Could you give us an idea of what tasks this job contain and what amount if
time we could expect to use on this job?

Thanks
Jacob

----- Original Message ----- From: "Oliver Zeigermann" <[EMAIL PROTECTED]>
To: "Slide Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Saturday, July 10, 2004 10:25 PM
Subject: Re: Slide 2.1 and Release Management




If stuff works out the way I plan I will be able to remain involved with
Slide. However, to a more limited degree that does not allow for release
management.

It's a pity you will not be able to take over release management :(

Anyone else? Think of all the fame ;)

Oliver

Unico Hommes wrote:


Oliver Zeigermann wrote:


Folks!

I want to bring up two (at least for me) important issues. One is the
Slide 2.1 release and one is the future release management for Slide.


Slide 2.1 Release -----------------

(1) What's in the pipeline?

First I'd like to know what you people have in the pipeline to include
in the Slide 2.1 release? Speaking for myself I would want to
- finish the JCA connector and
- do some more profiling and performance enhancements


Things on my agenda are: - stabalize DASL RDBMS expression factory - DACL enhancements (see mail from my collegue Johan Stuyts)


(2) Shall we release M2 or go directly for a beta?

I would like to go directly to a beta skipping the scheduled M2
release. The main reason for this will be explained below.

To clarify: I understand a beta includes a feature freeze, i.e. no new
features will be added after a beta.



I don't have a strong opinion either way but your arguments below are convincing. +1 for doing a beta release early August.



Release Management ------------------

I have been the release manager for the current 2.0 release and would
volunteer to take this role for the 2.1 release - provided we can get
the release cycle (beta -> release candicate -> final) finshed by end
of September or only a little later.



Thanks Oliver, you have been doing an awesome job IMO. Pity you're not staying :-(


Judging from experience this will be possible only if we release a
beta in early August - if at all. This is the reason I would vote for
skipping the M2 release.


Agreed.


The solution I would favour, though, would be to pass the role to
someone else *now*. This would make sense as I for sure will not be
available for it in a 2.2 or 3.0 (whatever will come) release. If
someone took over now I could still assist and introduce where I can.


I would nominate myself for the job of release manager, but I will be taking leave from my job to travel and study in a few months time and so I won't be able to do it.

Btw. as a way to perpetuate your experiences as a release manager
perhaps it is a good idea to wikify some of the things that are involved
in the process. See for instance
http://wiki.apache.org/cocoon/CocoonReleaseHowTo

--
Unico

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




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




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



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



Reply via email to