Defining the damn 3.9 process! (was Re: SqueakFoundation money)

[Adrian Lienhard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

thanks for the explanations, Ken.

On Dec 9, 2005, at 17:49 , Ken Causey wrote:

> On Fri, 2005-12-09 at 15:09 +0100, Cees De Groot wrote:
>> [...]
>
> I'm going to assume that 'the 3.9 team' is the same as the Harvesters.
>
>> [...]
>
> I absolutely 100% agree that issues should be reported on Mantis.
> However that does not mean that all reports will completely disappear
> from the mailing list even though they are slowly decreasing in
> frequency over time.  Currently the Janitors team catches new issues
> that appear on the list and confirms that there is a matching entry in
> Mantis or adds it if not.  This is not a permanent solution.
>
> !!!!!!!!!!

absolutely. You have been doing a lot of work moving bugs into  
Mantis. Maybe, you could now switch to the strategy where you just  
reply to bug reports on the list with "please, add to mantis, or else  
this will not be treated". The problem is  that people get the  
impression that if they report to mantis (e.g. see post of P.  
Marshall on Squeak-Dev today), nobody cares. But we are changing this  
right now, so this is good.

>
>> [....]
>
> I consider the Mantis Category to be the dispatching field.  Within  
> the
> Squeak project there should be at least one category to match any  
> issue
> and the main way to do that has been to create a category for each top
> level Squeak class category.  If any user chooses 'Any' as the  
> category
> then I get an email with their report and as soon as I can I go in and
> recategorize it.  So as far as I'm concerned dispatching is completely
> handled already and has been for months.

very good, I didn't know.

> [....]
>
> So, please let me know what is missing here.  I firmly believe that we
> can build a sustainable process and that Mantis can be used to  
> provide a
> communication and archiving mechanism for it.

yes, if we can avoid using wiki pages and model everything with  
mantis, even better!

so, it seams that the process from (i) creating reports -> (ii)  
assigning reports to categories already works well.

what needs work then is assigning reports to steward teams, that is,  
defining a mapping. Can this be made explicit on Mantis? Very useful  
would also be one report per team (and not per category) to raise  
visibility what work is pending for each team. Is this possible?

Then, this leads to the issue that there are a lot of missing teams.  
As you suggest, we could just make the release team the default  
team... but in the mid term the goal should really be to have most  
teams in place.

Moving fixes from (iii) fixing (steward team) -> (iv) integration  
(release team) can be done by moving into the 3.9a inbox plus  
changing the status on Mantis. Though, I would not take the status as  
trigger for the release team - it's not good to have this  
redundantly. Hence, the release team just polls the inbox.

A question that remains then is how the release team informs the  
steward team that a fix is integrated so that they can update Mantis;  
(iv)->(v), what I've suggested earlier?
Maybe we should change this idea, so that the release team changes  
the status to closed on Mantis. That's a bit simpler since it does  
not need an additional switch between the teams.

Anything missing or unrealistic? Probably the hardest thing is to get  
the teams up and doing their job... if we end up with that few teams  
and the default team is the release team, Marcus and Stef will still  
have the same load and we will not gain much...

Adrian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDmcWki1NjO2nP/WIRAtJBAJ4rWC9e7EPZ+t2KqcgFBJRJ5qQdlwCgkQvn
Sm3hlQPGym9Hd71xMaP+ijo=
=TDPP
-----END PGP SIGNATURE-----