Process

[Adrian Lienhard]

Hi all,

I think we should now decide about this last, in my opinion rather  
minor point, about who closes the issues.

Although I've been arguing with Cees before, the arguments of Ken,  
and also Stef saying he would prefer keeping this practice (that was  
what he was doing up until), I'd suggest to do it like Ken proposes.

Cees can you live with this? ;-). I mean, if this turns out to be  
really a big burden on the release team we can still change it later on.

It would be nice to actually start putting the process into place  
now. We are planning to do the SqS enhancement (to make the inbox  
usable) this week...

Adrian

On Dec 13, 2005, at 00:41 , Ken Causey wrote:

> 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