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

[Adrian Lienhard]

Since this whole thread started by me, here my 2 cents...

It always amazes me how much people write in the mailing lists at a  
"meta-level". Sometimes I have hard times to even catch up reading,  
not speaking of participating in the endless discussions. This thread  
has the subject "Defining the damn 3.9 process!", there are already  
15 posts, but not one proposes a concrete solution!

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

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

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

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

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


(2) probably is organized on a per case (project) basis, so it's a  
bit harder to set up a process. But I think, the following rules  
would apply:
- there is one responsible person of the project, probably one of the  
main developers
- he works together with the integration team to prepare the integration
- since probably several packages are touched, the responsible  
Stewards teams are informed so that they can review what gets in.

So, that would basically be the process, that I think can work, *if*  
there are enough people actually participating in it and taking  
responsibility. We should not need new tools, some "official" wiki  
pages should do the job.
Though, what I would like to stress is that transparency is really  
important: everybody should be able to immediately see the list of  
unassigned issues and the pending and the fixed issues of each  
Steward team. On Mantis I really have problems to follow what  
happens. E.g., I would like to have a RSS feed of any changes (I miss  
that since they do not appear anymore in the mailing list).

Adrian


On Dec 8, 2005, at 21:33 , goran at krampe.se wrote:

> Hi people!
>
> =?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
>> You are not facing the problems so this is easy to say.
>
> Ehm... we are all in this community aren't we? And we are both on the
> board. Sure, you are 3.9 team leader, and I am not - but I still think
> we are all in this together.
>
> And I stand by my words. Money is not the solution. But if it can help
> us - fine.
>
>>> Ok, so let me check what Teams we have:
>>>
>>> 	http://www.squeak.org/Community/Teams
>>>
>>> Aha! "v3.9" and "Packages" are the main teams for getting this  
>>> process
>>> defined. IIRC the Packages team stalled, but at least we adopted the
>>> packages orientation that Impara use and we also at least got the
>>> Steward idea rolling a bit. We now have 7 Stewards teams defined  
>>> (see
>>> above) and it is now very important that the v3.9 team defines  
>>> how to
>>> act with them and start working *with* us.
>>
>> You see sometimes this kind of email pisses me off. I should be
>> tired.....
>> so I breath slowly and continue to read....but as if we would not be
>> working
>> with people. WHAT are you really implying?
>
> I am implying that the 3.9 team hasn't made any visible steps to  
> show us
> (the Steward teams) how you want to work with us. I didn't mean to  
> make
> it sound "harsh" though - I was more trying to stress that it is
> important to not forget that we now have Steward teams and to make  
> sure
> we start benefiting from that.
>
> I am also implying that there is a culture of fixing things in the  
> image
> (since the dawn of time) instead of taking the time to funnel the  
> fixes
> to the upstream package maintainer. I am saying this primarily as the
> maintainer of SM which has been around for some time and I have  
> seen it
> happen over and over. AFAIK there are several fixes to SM in the image
> that have never been sent to me. Sure, I can pick them up there  
> myself -
> but the point is that people seem to take that for granted. Or they  
> seem
> to still think the image is the master, which it isn't - not for SM.
>
>>> Looking at the v3.9 list it seems slow right now:
>>>
>>> 	http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse? 
>>> list=v3dot9
>>>
>>> ...can we get some discussion *there* (and not on the board list or
>>> private emails) please and get this process defined? Take this as a
>>> STRONG hint to reply to this email on the 3.9 list and not on the
>>> board
>>> list. :)
>>
>> The traffic is the one that we can have.
>> Who is harvesting? Me!
>> PERIOD and right now we have been over intense tests to get traits in
>> an non
>> image hack way.
>
> I am talking about the Steward teams producing new revisions of their
> packages and how the 3.9 team will work to pick that up and integrate
> it. That was the whole plan IIRC.
>
> And btw, even though we haven't been very active yet in the Network  
> team
> - you can't really know how much we are working. For example, today I
> sat scavenging Mantis for Network stuff (and there is plenty to work
> with), but you wouldn't know.
>
> I also highly appreciate what you are doing - I just think you  
> might be
> forgetting or dropping the ball on the Stewards idea. I need you to
> "drive" that process - because you are in charge of 3.9 - which is the
> target for the Stewards teams. And by driving I mean showing how you
> want us to work with you.
>
>>> Now, my challenge to the v3.9 team is to concoct a process based on
>>> this. As you can see above the Network team has decided to always  
>>> work
>>> with the latest published image from 3.9 and we will  
>>> produce .mcz's -
>>> both for our package and possible bundled with .mcz's for other
>>> packages
>>> that need to be modified. And we decided that we decide together
>>> when to
>>> push stuff to you guys - typically when we think we have "enough
>>> goodness" bundled up - we don't want to push too often.
>>
>> ok
>>
>>> Now, *how* do we "feed" you guys? Do we throw them in your inbox  
>>> *and*
>>> send a corresponding mandatory email to the v3.9 list (seems
>>> reasonable)?
>>
>> Yes
>
> Ok, good. Can we get this written down somewhere?
>
>>> And if this is a good process - when you decide to muck
>>> about in our package :) how do you handle *us*? We are *upstream*
>>> now -
>>> so I really, really hope you realize that you must respect that (or
>>> else
>>> the Steward idea falls apart from the start)
>>
>> Why are you talking about respect?
>
> I was referring to the fact that seemingly stuff has been happening in
> say Network even after we formed the Stewards team for it. Sure, it
> seems to be mainly UIManager stuff etc, but also some fixes from ac  
> (?)
> got in it seems. And yes, that was Cees doings :) I think, but it
> doesn't matter - my point is that it wasn't pushed to us.
>
>> For me this is simple we do not harvest anything that has a team and
>> we wait
>> that the team push code that we need to integrate. We work until the
>> integration is working.
>
> Good. Perfect. And I am sorry again for bad choice of words. Ok? :)
>
>>> and that you feed your
>>> proposed changes back to us so that we can review, integrate and  
>>> feed
>>> them back to you. Or something like that.
>>
>> Yes
>
> In fact, I could even be fine with you putting proposed changes  
> directly
> in the image, just as long as you send us an email for us to decide if
> it is fine. Mostly it is probably fine, and if not we can always back
> out. This might work faster - at least for things like the UI work  
> Cees
> did since it spans so many packages. If it is local fixes - then  
> sending
> us an MC is better. Or rather putting it somewhere in a repo that  
> we can
> pick up. An "outbox". :)
>
>>> Ok, now you get an idea of what I would like the definition to
>>> include.
>>
>> Definition of what?
>
> Of what we are describing here. The process for how we work  
> together on
> 3.9 (the 3.9 team + the Stewards teams).
>
>>> In short - the rules for the flow here.
>>>
>>> regards, Göran
>>>
>>> PS. I am confident we can do this, so let's get it done.
>>
>> Me too.
>
> :) And Stef - sorry if my words came out harsh. Ok?
>
> regards, Göran