Process

[goran at krampe.se]

Hi fellas!

Cees has been explaining quite a bit of the "effects" of this
one-MC-per-issue-and-integrators-close-them-approach, but I wanted to
reply anyway:

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

I believe that too (emphasis on Mantis) - I just don't believe that the
last step is crucial to document. Or in other words - I want the
granularity of the release team to be *packages* and not *issues*.

So the idea is that the Steward team handles the issues in Mantis more
or less totally. And feed *package releases* to the release team. Each
release of course has a "changelog" with links to fixed issues etc.

The only next step to really "document" is what releases that the
current release image contains. So an example:

I see an issue in Mantis, it says "fixed in Nework-gk-3.44 or whatever".
I check my image, oops - it has 3.43. I can fetch the 3.44 manually and
try to use it or wait until 3.44 gets integrated.

All in all this mirrors how the Linux distros work in cooperation with
the upstream software packages.

>  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

As I have said my killer issue with this is that it seems so very
impractical and uncomfortable to force the Stewards (and other teams?
Cees asked that too) to submit ONE issue per MC to the inbox.

IMHO the release team integrate *packages* not *bug fixes*. The Steward
team is responsible for a *package* and should make *releases* of that
package. I translate a release into a compound (=containing several
fixes, enhancements, cosmetics and whatever) MC with a corresponding
changelog (typically included in the version comment with links to
relevant issues in Mantis).

Forcing the Steward team to submit a single issue per MC is... well, it
quickly turns messy. Let's say there is an issue that triggers a
refactoring - not an uncommon scenario of course. Let's say that
refactoring actually solves 2 issues :). Well, you see where it is
going.

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

I still think the focus should be on the package. The Stewards team
marks it as resolved and points to an MC release of the package.

Sure, we can add the step that the Steward team *closes* the issue when
the release in question is integrated into the image - but I am having
trouble seeing the great benefit. The issue already lists the specific
package release that it is fixed in, and the 3.9 image already lists
which specific package release it has currently.

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

IMHO the only verification they should be doing is getting a grip on the
larger picture of the changes in the release (reading the version
comment - perhaps "playing" with things to understand it) - but not
detailed "reviewing". And run unit tests of course.

I don't think they should be "verifying the fixes" actually. I think
that is the Steward team's problem, both at package release to the inbox
- and afterwards when it has been integrated. The release team will
never have the capacity to verify things in all packages - because they
simply don't have the knowhow.

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

This is more or less what I want - the difference was that I thought the
issue was closed when there was a tested new release of the package
available. Just like an issue in the Apache server is closed when it has
been fixed in the latest available Apache - not when the latest RedHat
has been released with it. :)
 
> 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.

Not sure what you mean there.

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

Eh... I don't think we have the same mental image. :) I want someone to
spend a little time with the latest Network package release when we make
it available in the inbox - read the version comment, perhaps notice one
or two things about it and correlate with other packages likely to be
affected etc. But I don't see the release team going through every line
of code and reading every issue on Mantis when integrating. That is just
TOO much unnecessary work IMHO.

Let's try to get a bit flexible, agile and "rad" here. :)

regards, Göran