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

[Ken Causey]

On Fri, 2005-12-09 at 18:57 +0100, Adrian Lienhard wrote:
> -----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.
> >
> > !!!!!!!!!!

Oops, the exclamation marks were here to remind me to go back and add
something more and it didn't work.  No emote intended.

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

Well, we 'did' a lot of work.  But other than being too easily annoyed
by silly things very little time is spent on it anymore.  I don't think
I processed more than 3 or 4 reports in the last month and I basically
am the Janitors team currently.  Each time I process one I do include a
request to use Mantis in the future.  I think the 'impression' issue is
going to have to be handled by forming teams, developing a process, and
getting it chugging.

> 
> >
> >> [....]
> >
> > 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?

You've totally lost me here.  I thought I answered that already.
Steward Teams signup to cover one or more Class categories.  For each of
those there is a category in Mantis.  So when a report is created and a
category is assigned, that chooses the steward team.  Done.  What am I
missing?

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

Yes, and I appreciate any suggestions on how to get more teams to
signup.  We've been fussing and fuming over this for over a year and the
current state is the best we've been able to manage so far.  I'm afraid
we are just in a situation where the availabled manpower for Squeak is
low.  I suspect this is just temporary and we need to figure out how to
manage until it improves.  My best idea is to add more members to the
release team and get the process sorted out so that, as Cees suggests,
someone can spend 15 minutes to an hour and get something done.

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

Why can't the release team update Mantis themselves?  Maybe I wasn't
clear.  I think it is best if Mantis is used for the primary
communication mechanism regarding fixes by everyone.  SqueakSource would
simply be the tool for storage of the new bits and the mechanical
process of incorporating those into the update stream.  So the release
team would scan Mantis for 'resolved' issues.  The issue would either
include the fix which they would download, or better note the name of
the related fix in the inbox, the release team member would do his
thing, then mark the issue closed assuming everything is kosher.

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

No, I don't like it.  We have lost fixes between the submitted and
incorporation stages before.  I think it is very important to
differentiate between these two stages.

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

Yes, priming the pump is turning out to be the hard thing.  But
developing a clear and simple enough but not too simple process with
instructions should help there I hope.

> 
> Adrian
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFDmcWki1NjO2nP/WIRAtJBAJ4rWC9e7EPZ+t2KqcgFBJRJ5qQdlwCgkQvn
> Sm3hlQPGym9Hd71xMaP+ijo=
> =TDPP
> -----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/v3dot9/attachments/20051209/4315b646/attachment.pgp