Process

[goran at krampe.se]

Hi fellas!

Ok, first I like to say that the discussion has been fruitful. For once!
:)
As Adrian noted we are pretty much on the same page, except for some
details about how to keep Mantis in shape. In this case I am all with
Cees actually, but I can possibly (just like Cees) be persuaded in
another direction.

Now some comments:

Ken Causey <ken at kencausey.com> wrote:
> On Sun, 2005-12-11 at 21:49 +0100, Cees De Groot wrote:
> > On 12/11/05, Adrian Lienhard <adi at netstyle.ch> wrote:
> > > Ken argued that it would be better to track each step on Mantis. I
> > > think Stef's (see his reply below) means the same.
> > >
> > > How do we decide?
> >=20
> > Well, I think I sort of missed why it would be good to burden the
> > integration team with Mantis administrativia - if the proponents could
> > point out their arguments, we could sleep over it and then see how
> > everyone involved thinks :).
> 
> I think it is extremely important that the entire process be completely
> transparent.  To this end I believe it should be documented in one place
> and for the moment the Mantis issue seems like the best place.

AFAIK we all agree on the above. Or am I missing something?

> I don't understand why you consider the following to be a burden:
> 
> 1.  When the person who submits a 'fix' to the inbox submits it he
> includes the URL to the report in Mantis in the description.

My first comment is that the Network team will push consolidated MCs
containg several fixes at once. At least as long as I am the team
leader. :) Single fix MCs by individuals will be published in the
Steward repo - and then combined when time comes to push.

So the comment will list a range of issues fixed.

> 2.  The release team member that harvests the fix clicks that link.
> 
>   2a. If the release team member is not already logged in (login can be
> saved when logging in which sets a cookie and does not require you to
> relogin every time you go to the site) then he logs in.
> 
> 3.  The release team member selects 'closed' from the 'Change Status
> To:' and hits the button.
>
> 4.  The release team member adds a quick note explaining that this fix
> was harvested in update X and hits the button to mark the issue closed.
> 
> > Summary of 'my' position: it is not necessary to burden the
> > integration team with Mantis work; we could track everything just as
> > well by having the stewards team point to Mantis in their MC comments
> > and vice versa.
> 
> But it's not tracked in one easy to find place.  Also I see the problem
> that a single issue is not mapped necessarily to a single MC and so the
> question then becomes do you annotate the same information in every
> associated MC.

Mmmm, for starters - I will never push one MC per fix/enh. It will not
only drive me/the Network team crazy (IMHO), it will also drive the
release integrators nuts. IMHO. :)

And why is it not "tracked in one easy to find place"?

The only difference I can tell is that the Steward team does the close
(when pushing to inbox) instead of the release team doing it when
integrating. The issue in Mantis points to that MC(s) - and the MC
points back in the version comment - so no difference there.

The effect is IMHO that the release team can - for most part - just pick
up MCs, integrate them and see that stuff doesn't break. Most fixes are
small and this should IMHO mean that they can concentrate on the bigger
fish.

Another effect is that for these "smaller fixes" the Steward team takes
care of the Mantis issues from start to end, which seems good.

The release team can still re-open, change prio etc in whichever way
they like.

Ok, what are the possible drawbacks? Well, an issue can be marked as
closed - but still not be "in" the published image - it could be sitting
unintegrated in the inbox. Personally I don't think this is such a big
deal though. The benefit of the "swiftness" in this model seems to
outweigh this.

So this is my short version of "Process":

0. Issues gets posted to Mantis possibly including fixes, yaddayadda.

1. Janitors categorize them to "Network" (or whatever). Or the Network
team picks them up themselves.

2. The Network team assigns to individual members that work on the
issues possibly producing multiple MCs in the Network repo etc etc.
Eventually the issue is "resolved" by the member, and the MCs intended
to be pushed are queued up. These MCs of course mention the issue
numbers in the version comment.

3. Someone, like say the Network team leader, consolidates the queue of
MCs into a single one. Typically testing it together etc. And then
pushes it to the 3.9 inbox and closes the issues on Mantis.

4. The release team picks up the MC(s), reads version notes, integrates
and hopefully all goes well. Done.

In short - I want the bulk of the "drudgery" to be in the Steward teams
- not only for efficiency but also - and this is actually a bit
important - to keep the Steward teams as autonomous as possible. I think
that is an essential piece of the puzzle here.

regards, Göran