Process

[Adrian Lienhard]

I think you mix up two different things here:
(i) who closes the issue(s) on mantis (which was in question)?
(ii) whether a set of fixes should be committed to the inbox in  
separate versions or not?

I don't see why (i) would influence (ii). IIRC it was never in  
question that the Steward teams can push versions into the inbox  
containing multiple fixes, was it?
Just what's necessary is that each committed version lists the fixed  
Mantis IDs so that the release team can update the changelog  
accordingly (and has some clue about what they are integrating of  
course).

Therefore, (ii) should not be in question, right?
And still, still, open is (i).

Adrian

BTW: for my part, I don't think it will make any big difference, and  
both solutions are ok



On Dec 13, 2005, at 12:25 , goran at krampe.se wrote:

> 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