Hi Oliver, you certainly have my +1. I would not want to take the responsibility of a release manager myself, mainly because I am not experienced enough.
Regards, Ingo > 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]
