Hi Oliver, +1 from me!!!
regards, Martin -----Original Message----- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Dienstag, 11. November 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]
