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

[stéphane ducasse]

Hi ken,

All in all we agree. Now I can tell you that mantis does not help me  
to mark the items
I should not forget to have a look at.
I just realized that indeed we should have a look at the resolved  
points.
Then I'm often lost in the Mantis user interface.  Now the biggest  
problem for me is to
be more or less alone. I guess that marcus will come back but instead  
of wasting
marcus on harvesting, I would prefer that he work on integrating the  
method annotations
and the new compiler.

Stef


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