Great, Oliver! Your qualification for the task is *best*! Here is my +1.
Regards, Peter > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 11, 2003 12:55 > To: Slide Users Mailing List > Subject: Re: Slide 2.0 Release Management > > > OK, this means the RM needs commit access to the CVS. Thus > the RM must > be an active committer. > > Active committers are (sorry if I have forgotten anyone, > please tell me > if this is the case): > - J�rgen Pill > - Peter Nevermann > - Martin Wallmer > - Ingo Brunberg > > Additionally, there is one designated committer, which is *me*. > > I understand the people from SAG hardly will take the > position of the RM > as they have releases of their own server. Correct? > > This leaves Ingo and to a limited degree me. > > There can be no doubt being a RM is unpleasant and requires a > significant amount of time, as R�my said. That's way I dare > not to ask > Ingo, but rather propose myself for the job, even though > other certainly > have better qualification. If Ingo, the people from SAG or any other > committer wants the job, I will be even happier :) > > What do you people say? Especially committers since we - as > R�my said - > need three +1 from votes committers. > > Oliver > > Remy Maucherat wrote: > > > Oliver Zeigermann wrote: > > > >> Hi! > >> > >> I am not really in the position to answer that question as I have > >> never participated in a Slide release. Also the term > "release manager" > >> is not very well defined in general. Although, judging from what I > >> have seen in other open source projects and from what I > have learned > >> from this mailig list's archive is this: > >> > >> 1.) The release manager (RM for my laziness) will need > access to and > >> solid knowledge of the CVS. When there is a feature freeze > the RM will > >> either have to lock the CVS and accept fixes as email only > or create a > >> release branch and later merge fixes back to the HEAD. I'd say a > >> branch is good enough for a small project like this. Also > the RM will > >> have to do the tagging of milestones, releases, etc. > >> 2.) The RM keeps in contact with the users, contributors > and commitors > >> and communicates with Apache release people. > >> 3.) Actually *makes* the release. The RM decides when the > release is > >> mature, writes release notes, with known bugs, enhancements, > >> limitations, etc. > > > > > > For the release to happen, a vote from the committers is > also needed (at > > least three +1). > > > >> 4.) Runs the test suite to the code. Maybe this can be > delegated to > >> someone else? Anyway, the tester must have good knowlege > of the system > >> and an overview over the sources. The RM for shure needs > to guarantee > >> there is at least one clearly identifiable person per code part / > >> package. > >> 5.) Sees to the general documentation being up to date > > > > > > Other than that, nice summary :) > > I was the RM for Slide 1.0.x, but unfortunately it required a > > significant amount of time, and so I didn't want to do it > for Slide 2.0. > > > > R�my > > > > > > > > > --------------------------------------------------------------------- > > 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] >
