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 <[email protected]> wrote: > On Thu, Sep 2, 2010 at 18:28, Sascha Silbe > <[email protected]> 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 >> [email protected] >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Sent from my mobile device _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
