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.
