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

Sascha Silbe sascha-ml-reply-to-2010-2 at silbe.org
Thu Sep 2 12:28:00 EDT 2010

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100902/5ad3c119/attachment.pgp 

More information about the Sugar-devel mailing list