[IAEP] Devel Team vacancies

[Simon Schampijer]

On 06/06/2010 10:30 PM, Tomeu Vizoso wrote:
>>     <SeanDaly>  if tomeu were here, he would say: we need someone experienced, who knows the open source way, and does not need lots of briefing to get up to speed (he will correct me if I err)
>
> You can count on me for that :)
>
> So the idea of team coordinator is that of someone who takes care for:
>
> * keeping the list of team members updated in the wiki,
>
> * making sure the mission statement is in sync with the team's activities,
>
> * announce and moderate regular meetings and publishing its minutes.
>
> So I don't think you need any special skills, just be willing to
> donate a few hours per month.
>
> If we had a community team, we would have a structure for the people
> who want to work together on such issues ;)
>
>>     <cjb>  (I think the most important job the release manager does is decide whether a late change constitutes acceptable risk, and I think doing that requires deep understanding of programming and the complexity of a given bug/solution.)
>
> There seems to be a misunderstanding, maybe because OLPC had a
> position with the same name (and maybe our use of it is not totally
> appropriate). In Sugar's case, who decides what goes in and what not
> is the schedule, the maintainer and the release team, with input from
> several others.
>
> The schedule says what kind of changes can go in at every moment in
> the release cycle, the maintainer is expected to have enough criteria
> to classify every change accordingly and the release team votes on
> exceptions to the schedule.
>
> All about releases: http://wiki.sugarlabs.org/go/Development_Team/Release
> New features process and what is the release manager:
> http://wiki.sugarlabs.org/go/Features/Policy
>
> In this way, the release manager doesn't have as much responsibility
> as was implied in the meeting but he's mainly responsible for making
> sure that the process _for proposing new features_ is followed. It's
> largely an administrative role, but much more exigent than
> coordinating a team.
>
> The reason for having a weaker release manager and relying more on the
> criteria of maintainers is because by SLs being an upstream these
> decisions won't affect as directly to our users as downstreams are
> anyway expected to do integration, testing and maybe some amount of
> patching after each release is made. For a downstream such as OLPC or
> Fedora, someone needs to control very strictly what gets in at the end
> of the cycle because there's more pressure to get stuff in and because
> once you have sent the image to the factory or have started to seed a
> torrent it's much harder to go back and fix some bug.
>
> In the Sugar case, if a maintainer made a goof and introduced a major
> bug just before release, it will take some time before the code is
> packaged, then distributed to testers, then submitted to a stable
> release that users will use with some expectation of not finding major
> regressions.
>
> It would be great if people could search the wiki before entering in
> discussing a process or a role, because as you can see from the link
> above, that took someone quite a bit of time to write and would be sad
> to waste time discussing something else. Also, the docs in the wiki
> indeed could be clearer and any help will be welcome.
>
> To make it clearer:
>
> * the release manager is not needed to make module releases,
>
> * the release manager doesn't decide by herself if a change goes in or not,
>
> * the release manager makes sure the feature process is followed.
>
> Maybe a more appropriate name for what we call the release manager
> would be "new feature process manager" but as it's a bit long and we
> don't have a release manager, we ended up using that name instead.
>
> Regards,
>
> Tomeu

Thanks for taking the time to lay this out as detailed. It is true 
indeed that the main role of the release manager, as Sugar Labs 
interpreted that role, was to give a timeframe for the release. The 
release manager is setting the schedule and makes sure that the 
commiters are on track.

To control which Features will go into a release we have the Feature 
process [1]. The role of the release manager during the Feature Process 
is a sanity check, presumed in most cases to be a formality, to ensure 
that new features compliment Sugar guidelines and is manageable [2]. And 
if a Feature follows these guidelines there is no reason why it can not 
go into a release. However, if the Feature is not ready time-wise 
(Feature Freeze etc) it has to wait until the next release to land.

And the code review itself is handled by the module maintainers, like 
Tomeu described.

Regards,
    Simon

[1] http://wiki.sugarlabs.org/go/Features/Policy
[2]  http://wiki.sugarlabs.org/go/Features/Policy#Acceptance_of_a_feature