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