Process

[stéphane ducasse]

> First, thanks for Ken (cc'ed) for sharing his Mantis knowledge - it's
> good that someone can translate our theorizing into practical
> configuration stuff :-).

Yes

>
> Mantis -> (Janitors assign) -> Stewards team
?
Do not get the message

> Stewards team fixes bug:
> - Save MC version, commenting which Mantis bug was solved.
> - Close Mantis bug, noting the MC version that has the bug fix.

I was wondering if this is not better that we closed the resolved  
bug: the
resolution should include a mcz file and once it is integrated then  
we close
it. Else we may have to reopen it if this is not just working.
Doing that is simple as soon as the MC file contains the reference to  
the
mantis entry.

> Stewards team is proud of another day/week/... of bugfixing:
> - Pushes latest MC version(s) to inbox.
>
> Release team goes to work:
> - Integrates inbox versions
> - Pushes out updates and new image.

Ok I think that this is also important to be able that we
can influence the priority since a bug may simply block us.
This is also why I keep a page of todo because

> In other words, the release team is not involved with Mantis at all.
> It would be an extra burden on that team, and there's no necessity iff
> the Stewards do the bookkeeping: note the mantis bug number in the MC
> comment, not the MC version in the Mantis comment. If they do it
> structured ("Mantis #1234", "MC Files-CdG.1.mcz") we could even whip
> up a tool to browse Mantis, Inbox and update stream to track progress
> (and a hall of shame for bugs/MC versions that aren't linked ;-)). I
> think that requiring teams to structure their comments a little bit is
> a whole lot lighter than requiring the Stewards team to handle
> basically *all* Mantis bugs.

Indeed comments are reallllllly important. Especially when you have  
multiple packages
that introduce a functionality. Knowing that a set of files should be  
integrated together
is really important. I got some problems in the past.

Stef