Re: Fabio Massimo di Nitto release-managing XFree86 4.3.0-8
On Tue, 6 Apr 2004, Branden Robinson wrote:
> Okay. Daniel supports you, Michel supports you, I support you, and no
> one else has said anything.
>
> By unanimous consent of those who had the energy to grunt, the role is
> yours. :)
ehehe good.. time to do some work.
> As I conceive it, this means that branches/4.3.0/sid in SVN is basically
> your stomping ground.
Ok.
> To summarize an IRC discussion we had:
>
> 1) Changes should be made on the trunk, and *merged* onto
> branches/4.3.0/sid.
Exactly (see note below for unmerge).
> 2) Any committer can merge a change from trunk to branches/4.3.0/sid,
> *BUT* the commit message needs to indicate who tested the change set
> (and on what hardware, if applicable).
Please for everybody try to be as verbose as you can. Better one line of
log more than one less.
> 3) The release manager has the right to unmerge any change as unsuitable
> for release.
I would rather prefer to speed up both the process of merge/unmerge. After
you committed into trunk, the commit log will show up in the mailing list.
If noone objects to it within 48 hours, you are allowed to merge.
As RM i don't want to introduce any technical delay on your work. If we
disagree on a certain operation/patch/merge the same person that commit
the change will revert it. It is easier, faster and cleaner imho.
> 4) The release manager should decide on release goals. To do this, I
> suggest using the debian/TODO file; create a header for 4.3.0-8 and
> stick whatever items in it you think need to be done. However, if
> you have a better idea for documenting the release goals, go for it.
It is fine with me. Let's put out -8 at your discrection since i am still
in the mess of moving around and it would be exrtmely stupid for me to
delay anything from the beginning. From -9 we will go as i suggested in
the other mail. bi-weekly release or 10 bugs to close (with flexibility
and so on....)
> Over the next couple of days, I'll try and provide some examples of 1)
> and 2) with some of the several changes pending on the trunk. You can
> provide the example of 4), and of 3) if you really need to. :)
Perfect :-)
> Let's use this thread for discussion of any general release-management
> issues.
Agreed.
Fabio
PS I am back moving boxes and painting walls... ;)
--
<user> fajita: step one
<fajita> Whatever the problem, step one is always to look in the error log.
<user> fajita: step two
<fajita> When in danger or in doubt, step two is to scream and shout.
Reply to: