[Sugar-devel] Patch review (was: Re: Community)

[Marco Pesenti Gritti]

I agree. Two major advantages of reviews are higher visibility and a
process which is really easy to explain, we should not lose them.

Marco

On 9/2/10, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Thu, Sep 2, 2010 at 18:28, Sascha Silbe
> <sascha-ml-reply-to-2010-2 at silbe.org> wrote:
>> Excerpts from Tomeu Vizoso's message of Tue Aug 31 13:20:31 +0200 2010:
>>
>>> > What do you think about a model where we have some git repo that
>>> > everyone can commit to after they got, say, at least two Reviewed-By
>>> > (including one from a core / "long"-term developer)? The contributors
>>> > would get more testing of their work (=> less bugs in the release) and
>>> > the module maintainers would be able to pick resp. skip the patches
>>> > they
>>> > feel (un)comfortable with.
>>>
>>> But then we would need to resync at some point or merging would get
>>> worst with time?
>>
>> We could rebase after each release, like (at least some of) the Linux
>> folks are doing. Either on the master branch, or by creating a new
>> branch for each release (like the OLPC kernel repo).
>
> Sounds good.
>
>>> > Another idea would be a mailing list where early versions of patches
>>> > are
>>> > posted and can get some (incomplete) review. This would allow
>>> > contributors to get fast & easy feedback with a limited amount of time
>>> > spent for the reviewers. Reviews could just point out a subset of
>>> > issues;
>>> > a thorough review and deciding whether it's good enough to be merged
>>> > would happen like above.
>>>
>>> I liked how it worked in sugar-devel for a while, a separate mailing
>>> list would be also ok if the reviews do disturb people or whatever is
>>> the reason for having stopped doing that.
>>
>> To make it clear: Both the new mailing list and sugar-devel would carry
>> reviews. The difference is that RFC / PoC style patches would land on
>> the new mailing list, whereas those intended to get into mainline as-is
>> would be on sugar-devel.
>>
>> This would give a clear indication about whether a patch is intended
>> for mainline and also keep the "newbie" traffic off sugar-devel (IIRC
>> some people have complained about the high traffic on sugar-devel).
>>
>> The drawback is that we might miss some feedback from people who only
>> subscribe to sugar-devel but not to the new list. But then those are
>> probably the same people that would have complained about the increased
>> traffic. ;)
>>
>> An alternative would be to clearly mark patches with e.g. "RFC" in the
>> subject and create mailing list topics to allow filtering out review
>> related traffic. We already have "[ANNOUNCE]" and "[RELEASE]" topics
>> to allow anyone to receive only important announcements. The drawback
>> of this alternative is that few users notice this option and might
>> unsubscribe instead of activating the topic filter.
>
> I for one liked having patch submission and reviews in the same
> channel as we discuss other development stuff. But will subscribe to
> another mailing list if needed.
>
> Regards,
>
> Tomeu
>
>> Sascha
>>
>> --
>> http://sascha.silbe.org/
>> http://www.infra-silbe.de/
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

-- 
Sent from my mobile device