I think that the problem with commit-then-review would be the same problem I'm currently experiencing with our existing review-then-commit: nobody is doing any reviews!
In general, I like the review-then-commit because it keeps us from just breaking stuff all over the place. I don't really buy the idea that "trunk is for experimentation". A lot of the traffic that comes in is bug reports, to which I don't think it makes sense to just commit whatever someone provides - we want to actually *reduce* bugs, after all. For the things that are really experimental, I think we already do a reasonable job of getting them committed in as they are partially completed. I would be happy to start giving people more leeway to experiment in branches in the official SVN, if that would improve the situation. I understand that some people have been frustrated by the difficulty of contributing for a variety of reasons, but I don't think that means that we should just leave the door wide open in a way that would compromise code quality. I can assure you that if the only time breakages are discovered is when I'm rolling a release candidate, then releases will stop. What would make me incredibly happy is if I saw more comments from users that contained positive or negative reviews on patches. If there's apparent consensus on a patch, then I'm happy to commit it, but when I'm reviewing tickets that have nothing but a patch and a six-word comment from the contributor, particularly if it's not a language I use regularly, I feel like my hands are tied. I agree that we should be trying to recruit more committers. I'd be fine with Thrift lowering the bar as to what we consider "enough" to offer committership, but I don't really think that everyone who might be offered the rights would actually want them or follow through on the responsibilities. There's also a lot of overhead, including a fair amount of latency, involved in becoming a committer. I don't think that a casual contributor is really going to want to fill out paper forms and then wait two weeks before they can commit. It just doesn't improve their experience sufficiently. On Thu, Aug 12, 2010 at 3:19 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Todd, > > Would opening trunk to Commit-Then-Review and maintaining branches > using Review-Then-Commit help? That would involve folks using stable > branches in production... > > -- dims > > > On Thu, Aug 12, 2010 at 6:14 PM, Joe Schaefer <joe_schae...@yahoo.com> > wrote: > > ----- Original Message ---- > > > >> From: Todd Lipcon <t...@cloudera.com> > >> To: thrift-dev@incubator.apache.org > >> Sent: Thu, August 12, 2010 6:01:19 PM > >> Subject: Re: time for a reboot? > > > >> Hey look, a thread about me! > >> > >> The majority of my contributions were at my previous job, but I did get > >> committership and do the 0.2 release after joining Cloudera as Doug > said. > >> Cloudera does use Thrift internally, so having a stable release out was > >> important for us. > >> > >> I haven't been as involved in further releases because frankly, Thrift > does > >> what it's supposed to do and does a good job of it. What the ASF seems > to > >> see as a stagnating project seems to me to just be a mature one - > Thrift has > >> a single purpose, achieves it effectively, and does a good job for lots > and > >> lots of people including both my former and current employers. The > major > >> issues I've run into (and seen coworkers run into) have had to do with > the > >> release packaging and build, which we've improved a bit, and will > improve on > >> the distribution side of things as people like Debian start packaging > the > >> bits. > > > > My concern is more that Thrift has become a 1-man show over the past > > year than that there is stagnation here. Jira tickets get filed, commits > > happen, and eventually releases happen, but that's all being done by the > > heroism of Bryan. Apache projects are collaborative in nature, and > > usually committers care enough about one another not to let one person > > carry the project along all by themselves. If there isn't sufficient > > interest amongst the current committers to participate in development, > > perhaps we should be recruiting from those filing patches in Jira. > > > > With respect to commit-then-review, httpd has had that as its policy > since > > the very beginning, and it manages to produce consistently stable > releases. > > Ditto for the subversion project. Hadoop is certainly not the model of > > Apache-style version-control tree management that others should aspire > to, > > FWIW. There are serious internal concerns about the overall health of > the > > hadoop development ecosystem as it continues to evolve towards a 1.0 > release. > > > > > > > > > > > > -- > Davanum Srinivas :: http://davanum.wordpress.com >
