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