On Thu, Sep 2, 2010 at 18:28, Sascha Silbe
sascha-ml-reply-to-201...@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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
