[Sugar-devel] Sugar 0.88 packages
Tomeu Vizoso
tomeu at tomeuvizoso.net
Fri May 14 02:59:46 EDT 2010
On Thu, May 13, 2010 at 22:07, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Thu, 13-05-2010 a las 20:23 +0200, Tomeu Vizoso escribió:
>
>> This implies that we are using the old process because nobody has come
>> with a concrete proposal for changing it. AFAICS, the discussion has
>> stalled because of lack of interest from its proponents. Once we agree
>> on specific changes, the process docs in the wiki will be updated and
>> it will come into effect.
>
> Ok, you're clearly in denial :-(
>
>
>> And I'm supposed to track patches in the ml myself? I thought we
>> wanted to reduce the load on the maintainers because we had few?
>
> All the maintainers have to do is reply with:
>
> Acked-by: name <email>
>
> Then, the poster will commit the patch or find someone who will. You've
> probably seen this happen a few times on sugar-devel too.
>
> In other projects, the maintainer is the only person who has commit
> access to their tree, so they go ahead and merge the patch directly.
>
>
>
>> I have noticed that several of the patches that I have reviewed this
>> week could have been approved by now if somebody would have
>> pre-reviewed them.
>
> You're obviously disregarding the reviews done in the list. Almost every
> patch posted was reviewed (either successfully or not).
>
>
>> > iirc, you were opposed only to let any contributors approve patches for
>> > Sugar modules with missing or unresponsive maintainers.
>>
>> I don't understand what you mean, can you rephrase?
>
> My initial proposal to unstuck the review process was to let any
> existing Sugar contributor approve patches posted by others.
>
> You'll certainly remember this, because you commented that only those
> who are able to appreciate the maintenance burden of a patch are to
> decide on it.
>
> That's fine, as long as there are enough maintainers to review patches
> in a reasonable amount of time. If this is not the case, we could tune
> our requirements for becoming a maintainer so that we'll have more.
>
> There are many solutions to the problem of maintainer shortage, just
> pick your favorite one. Except, maybe, halting development until the
> planets come to the right alignment and maintainers of your liking start
> to fall from the sky.
>
>
>> How can you vote before you have a proposal? Or the proposal is "do
>> whatever the linux kernel does"?
>
> Would you like me to open a bug in trac and attach the proposal to it so
> you can review it?
>
> We've discussed the email-based review process once on IRC, in which you
> agreed and asked to post the proposal to sugar-devel@, then a second
> time on the thread following Sasha's summary. There was also a third
> time, on the "Patchwork" thread. In all cases, you claimed to be in
> favor for the general idea except for some minor points which I believe
> have been addressed.
>
> Tomeu, please, let's not start over from the beginning.
I'm just asking for someone to propose a set of concrete and coherent
changes to the current process, is it really asking too much?
I'm sorry but I cannot go through the old threads, ask individuals for
clarifications, then draft that new process myself.
Regards,
Tomeu
> --
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
>
>
More information about the Sugar-devel
mailing list