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

[Ken Causey]

On Fri, 2005-12-09 at 15:09 +0100, Cees De Groot wrote:
> On 12/9/05, Adrian Lienhard <adi at netstyle.ch> wrote:
> > ok, now, who does lead the investigation and reports possible
> options
> > so that we can decide what to do? Cees?
> >
> Ken is probably the right person to do this, because he has the most
> Mantis knowledge and thus can translate any wishes directly in terms
> of what Mantis can and can't do.
> 
> Ken: I'm not sure whether you are a member of v3dot9 but the idea is
> that we want to track Mantis bugs from stewards team to inbox to
> integration team to integrated - Adrian wrote a bit on that so it's in
> the archives; the idea is to translate this to a Mantis flow and ask
> Impara to make any necessary changes. Only if they say no, we will
> look at an alternative process e.g. based on Swiki's. Would you be
> willing to help there?

No, I'm not a v3dot9 list member but I'll see what I can do.  Frankly I
don't have the time to read all of this but I scanned the thread and I'm
going to use Adrian's proposal as a basis and add my own comments.

Adrian Lienhard <adi at netstyle.ch> said (8 Dec 2005 23:21:41 +0000):
> Said that, here my suggestion:
> 
> I divide the tasks for 3.9 into two parts: (1) "bugfixing/small  
> enhancements" and (2) "bigger features/tools/projects" (e.g.,  
> traits), latter probably spanning several packages.
> 
> (1) typically has the following flow:
> (i) reporting issues on Mantis
> (ii) analysing and assigning new issues and (iii) fixing or
> rejecting  
> them
> (iv) integrating fixes in 3.9
> (v) updating Mantis reports and give feedback
> 
> Now, who is responsible for what? There are the 3.9 team, the
> Steward  
> teams and the users of Squeak:

I'm going to assume that 'the 3.9 team' is the same as the Harvesters.

> (i) Reporting an issue: A user reports an issue on Mantis. He wants  
> to be informed about what happens to it, and this should not take
> too  
> long. Important steps taken in the following process should be  
> reported to him.

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.

!!!!!!!!!!

> (ii) Assigning issues: After an issue has been reported, there need  
> to be some dispatcher, a responsible person that regularly checks
> new  
> issues and assigns them to the responsible Steward team. The issue  
> report on Mantis has to show who is responsible (or there has to be  
> another place where all issues are listed). On Mantis we have a  
> Category, which seems to be that, but there has to be a mapping, so  
> that no reports can be unassigned.

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.

Notification is a seperate issue.  To each category a Mantis account can
be assigned. When a new report for that category is created an email is
sent to the email address associated with that account.  When I've had a
clear idea of who to assign a category to, then I've done so.  Currently
11 of the categories have been assigned to someone which is about a
fourth or so.

> (iii) Fixing pending issues: At this time, each report is assigned
> to  
> exactly one Steward team. According to the web site (http:// 
> www.squeak.org/Community/Teams), though, there are a lot of missing  
> teams. So, a team for the "rest" would be needed. I think it is  
> important not to have gaps. Each team is responsible to deal with
> the  
> issues (fix it, reject it, etc.).
> The team works on the latest 3.9, creating new MC package versions  
> for each issue. Finished packages are put into the "inbox" of 3.9
> and  
> the integrator team is informed (only committing to the inbox does  
> not work!). I would suggest to maintain a wiki where each team can  
> put items that need to be integrated. This is to keep track of them,  
> in addition, email between the teams should work.

Yes, I believe that the teams are crucial.  And I believe that there
should be a mapping of one or more Mantis categories per Steward Team.
When a new report is created and the category is set this assigns the
issue to the team.  Now of course it may well turn out that the issue
has been misidentified, I suspect this will happen regularly.  In that
case the team to which the issues has been signed should recategorize
the issue therefore directing to the more appropriate team.  In some
cases an issue may concern more than one team.  In that case I suggest
an email exchange between appropriate teams to discuss the appropriate
solution.  It may be appropriate to split the report into two reports
and categorize them appropriately.  At any rate in the general sense
teams will be assigned reports by category.

And right now the number one issue is that we are missing teams.  That
needs to be fixed, but as I see it the release team is the backstop for
the Steward Teams.  Any issue (Mantis category) which cannot be assigned
to a steward team is by default assigned to the release team.  At that
point the release team is reponsible and can handle the issue themselves
or maybe assign it to another team if appropriate, etc.  And by the way
I think that it is in the interest of the release team to have the
assistance of the steward teams and so I think it should be actively
recruiting for the missing teams.  Of course I realize that in practice
that takes time and if Stef is the only team member then it would be
difficult.  But this seems more realistic to me than trying to do
everything by one's self.  But the release team needs more members
itself also.

As you say once an issue has been assigned to a team that team should be
regularly looking for new issues and then assigning them to appropriate
developers.  That developer and perhaps other team members would then
work with the reporter and perhaps any other appropriate teams or other
community members to work out a resolution for the issue.  During this
process it is very important to update the status of the issue in Mantis
and add notes to explain what is going on.  Once the team believes they
have reached an appropriate solution then the issue should be updated to
'resolved' status and the note should clearly explain the resolution and
if a fix is involved where the fix can be found.  That could be as
simple as just attaching the fix to the Mantis report.  However it would
be better (and easier on the release team) to submit them to the
'inbox'.  But when that is do also please include the URL to the inbox
submission in a note on the Mantis issue so that users that need the fix
sooner than later can download it while they are waiting for the fix to
appear in a released image.

At that point then the issue is in the hands of the release team.  They
should actively be looking for issues in the Squeak project that have
been marked 'Resolved'.  When the release team then releases an update
with the issue which effectively ends the process then the release team
should mark the issue 'closed' and clearly note at what point (update
number perhaps) the issue was fixed in the image.

Now it has been discussed, and I agree, that optimistic harvesting is a
good idea.  I think we should be careful about it but trusted teams
should be given the right to issue updates directly.  That means that
the release team would not be involved in the process at the 'resolved'
stage but instead the steward team would move the issue forward to the
'closed' stage.  

I don't see the value of a wiki here.  I think it is much much more
preferable to have the entire process documented in one place and I see
no reason that the Mantis report should not be that place.

> (iv) Integrating issues: the integration team (=3.9a team) picks  
> items from the list, merges the packages, looks at the changes and  
> makes sure they do not break and can be loaded. When the new version  
> is integrated, the team marks the item on the wiki as done and  
> reports that to the Steward team. After the integration of a change,  
> the ScriptLoader is updated. Like this, everybody can immediately
> get  
> to the most recent version of the image by updating ScriptLoader and  
> run the latest #updateFromXXXX script. Regularly, the team updates  
> the update stream and creates new images.

I discussed this above to some extent.  I agree some standards as to
what make a 'good' fix should be formulated and I think you are on the
right track here.  I think the exact balance as to what the steward team
and the release team do regarding this can be tuned and will vary from
one team to another according to their trustworthiness and their
relationship with the release team.

Issuing new images is of course the responsibility of the release team.

> (v) Complete issue: After the Steward team sees the issue being  
> integrated, it closes the report on Mantis and reports that to the  
> creator of the issue.

Updating the Mantis report will automatically send an email to the
reporter.  Unless they have configured it specifically to not send them
a report.  But that should be up to them

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.

Ken
-------------- 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/802cc483/attachment.pgp