Process

[Ken Causey]

On Mon, 2005-12-12 at 22:44 +0200, goran at krampe.se wrote:
> 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?

For a while it seemed to me that we did not agree that the last step
needed to be documented:

penultimate step: fix is accepted by the team and submitted for
inclusion in an 'official' update.

last step: the fix is actually incorporated into an update making it
fully public and finalizing the issue.

Now it appears that we more or less agree that these should be
documented but not on the 'how'.  I believe that the entire process
should be documented in the Mantis issue.  At the 'penultimate' step the
team member would mark the issue as 'resolved' and include the full URL
to the submitted fix in the inbox so someone in a hurry for a fix could
download it if they like.  At the 'last' step whoever actually adds the
fix to the update stream (or whatever the mechansim is at the time), be
that a release team member or a steward team member, that person would
mark the Mantis issue 'closed' and include a notation of the update
number of version that includes the fix.

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

My concern is not WHO does the close, but WHEN it is done.  I don't want
the issue to be closed until it has been fully handled and is available
to everyone at least as simply as downloading a new image or loading an
update to the most recent image.

My misunderstanding lies along these lines:

Either

1.  The release team is actually doing some verification of the issue.
In that case then they need to already be looking at the Mantis issue so
that they understand the issue and have some ability to verify the fix,
and it should take no more than a few seconds to mark the issue closed
and add a one liner saying 'in update 6938'.

2.  The steward team pushes the release through the entire process all
the way to an update and so the relevant team member should already be
looking at the issue and be in a ready position to close the issue and
add the update number note.

I see no value in having a system where the release team has to spend
time accepting issues but does so with no information about the issue.
It seems to me if we need standard checks for slips and running tests
and the like then that can be done automatically as a result of a button
push to incorporate the fix into the update stream no matter who does
it, release team member or steward team member.  Why have someone spend
time on the issue but not expect them to have any understanding of it?

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/v3dot9/attachments/20051212/bb1a0f38/attachment.pgp