I understand what Todd is saying about stability and the cost of change, and it's something that Rapleaf has encountered, too. However, I think stability should be an *end goal*, not necessarily our current goal. I think we should be aiming to make all the traumatic changes that we might need before we hit 1.0, and then proceed with greater caution. If this means that we should change our processes to get out of the way of those who wish to make exploratory changes now, then I'm for that.
On Thu, Aug 12, 2010 at 10:06 PM, Joe Schaefer <joe_schae...@yahoo.com>wrote: > ----- Original Message ---- > > > From: Todd Lipcon <t...@cloudera.com> > > To: thrift-dev@incubator.apache.org > > Sent: Fri, August 13, 2010 12:57:52 AM > > Subject: Re: time for a reboot? > > > > On Thu, Aug 12, 2010 at 7:20 PM, Joe Schaefer <joe_schae...@yahoo.com > >wrote: > > > > > I both respect and agree with your remarks. With respect to the > delay > > > between considering someone for committership and actually becoming > one, > > > it's true that it is a process that spans several days if not weeks. > > > However > > > we really aren't looking for drive-thru committers, we want people who > > > will show sustained dedication to the project, spanning several months > > > if not years (iow Todd's committership here so far hasn't been > something > > > I'd consider a success). Remember it's community over code at Apache. > > > > > > > > In my defense, when I was nominated for being a committer, I did say > that my > > plan was to help with the 0.2 release and then likely step back. As I > think > > is the case for every person who works on Thrift, Thrift is not a > primary > > responsibility. It seems your stance above indicates that the only > > "successful" committers are those who spend substantial time on the > project > > every week - this seems counter to your earlier point that the bar for > > committership is too high. > > > > As a central piece of infrastructure, Thrift *should* be a slow moving > > project. It would make me very nervous if it released more than a couple > > times a year! As a random datapoint, I've heard from within Google that > the > > move from Protocol Buffers v1 to v2 was an incredibly disruptive change > that > > took more than a year to do throughout the organization. At a much > smaller > > scale, I've seen the upgrade from Thrift 0.1 to 0.2 burn about a > man-week of > > development time internally due to changes in the generated Java code -- > so > > you can see that releases with breaking changes have a large cost and > hence > > the team is reasonably cautious about any changes that might cause them. > > > > The Apache mantra is "community over code", and in this case, the > community > > is voting that they want the code to not evolve rapidly. It's a stable > piece > > of infrastructure and should be treated as such. Perhaps those who have > been > > working on some more experimental changes would like to weigh in here if > > they feel like their contributions have been unfairly treated? > > AFAICT the changelogs for the last 2 releases do not bear out your > suggestion that Thrift is an incredibly stable project. Neither > does the fact that over 800 issues have been filed against this > codebase since it's been brought here. Just today someone complained > about a bug report taking over 1 year to be addressed. The fact is > that there is plenty of work to go around and only 2-3 people actually > doing it. That is the reason it is a slow-moving project IMO. Unlike > cassandra people are STILL running thrift in production with local mods > instead of using straight releases. Reading the email stream today alone > tells a rather different story than you appear to believe is true. > > > >
