[IAEP] [Sugar-devel] Proposal release management

Tomeu Vizoso tomeu at sugarlabs.org
Fri Jun 25 03:21:18 EDT 2010

On Thu, Jun 24, 2010 at 20:05, Michael Stone <michael at laptop.org> wrote:
> Simon wrote:
>> What do others think about this?
> I'm glad that you have a proposal that excites Bernie, Bert, and Tomeu.
> I'm not sure what to think for myself because I don't know whether I
> correctly understood your intent from my reading of your, Bernie's,
> and Tomeu's words. (See below.)
> Bernie and Tomeu wrote:
>>> Regarding proposed patches, during our development cycle we have
>>> collected a number of patches fixing bugs and adding small features.
>> Just in case, note that the RM doesn't really care about what code
>> goes in as long as features have been approved and we are in the right
>> moment in the cycle (no freezes apply).
> Let's be clear: I want *nothing* to do with any software process that works
> this way -- you've described a bad shell-script, not a release manager.

First, the people who step forward to take roles such as this deserve
all our consideration and gratitude. Supporting processes is a job
with little glory but very important so the rest of us can keep doing
our work. That said, if you can write a shell script that produces
better release notes, please don't keep it for yourself.

Second, you seem to be thinking of the RM role as it exists in
downstream organizations. I suggest you to read about how releases are
made in other organizations such as GNOME and Fedora, and try to
understand how different they are.

It makes sense because the inputs and the outputs are totally
different, why both would have the same processes?

I recommend that if you want so hard to be a RM that tells what
changes go in and which not, that you offer your help to downstream
projects such as OLPC, F11-XO1, SoaS, etc.



> However, I'm not sure that this description is actually what Simon was
> talking about. Perhaps we should instead be talking about whatever role
> describes the people who /do/ care about the code that goes in?
> Michael

More information about the IAEP mailing list