[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


> 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.



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: