Process

[stéphane ducasse]

You lost me.

But I like the idea of packages vs. issues.
We can agregate several bugs/enh in one package.


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

exact!
Expect on crash :)
>
>> 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