You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Oliver Zeigermann <oz...@c1-fse.de> on 2003/11/11 08:58:07 UTC
Slide 2.0 Release Management / WAS E_HREF
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.
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
Oliver
K.C. Baltz wrote:
> What would a release manager be required to do? Would they need to be
> familiar with the code on a committer level? Or would they simply have
> to regularly ping the committers for status and in general try to keep
> things moving?
>
> K.C.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: Slide 2.0 Release Management
Posted by Ingo Brunberg <ib...@fiz-chemie.de>.
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: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: Slide 2.0 Release Management
Posted by Oliver Zeigermann <oz...@c1-fse.de>.
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: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: Slide 2.0 Release Management / WAS E_HREF
Posted by Remy Maucherat <re...@apache.org>.
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: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org