Alright, including James' email to me directly, that's 2 for CTR and 3 for RTC, so RTC it is!
A. On Mon, Aug 8, 2011 at 9:58 PM, Eli Collins <[email protected]> wrote: > Note that in both CTR and RTC there is code review, the decision is > whether the commit can come first. > > My suggestion would be RTC, and if that's moving slowly than move to > CTR, perhaps have a 1 day timeout. But I don't feel strongly either > way. > > IMO the most important thing is to devote review bandwidth to new > contributors so we can grow the project. > > Thanks, > Eli > > On Mon, Aug 8, 2011 at 7:23 PM, Bruno Mahé <[email protected]> wrote: > > On 08/08/2011 10:06 AM, Andrew Bayer wrote: > >> Hey all - > >> > >> I'm calling a vote on whether we should go with review then commit > (R-T-C) > >> or commit then review (C-T-R). See definitions at > >> http://www.apache.org/foundation/glossary.html. The vote's open for 72 > >> hours, and is open to anyone on the committers or mentors list at > >> http://incubator.apache.org/projects/bigtop.html. Thanks! > >> > >> A. > >> > > > > I vote +1 for R-T-C. > > We are far from being behind the number of patches to review, and so far > > I believe most of them, if not all, have been reviewed within a day. > > Given these packages are meant to work across a wide variety of > > distributions, it is very easy to let some bugs slip through and break > > bigtop for some GNU/Linux distributions. Furthermore we don't have any > > job set up on jenkins to confirm whether a patch break something or not. > > And even if we do get some slaves by 0.0.1 or 0.0.2, there will not be > > as much coverage as there should be. > > So I would welcome some extra pairs of eyeballs on patches. > > > > >
