Actually the C glib thrift bindings are already in git http://github.com/mlum/thrift
and seem to be forked of of http://github.com/dreiss/thrift which itself is supposedly "a mirror of The Unofficial Thrift Git Repository" so it seems like there is some sort of git happening out there, and Michael was attempting to use the git model for his development. However, I believe there was also another effort here http://sourceforge.net/projects/cthrift/ which was a completely different approach to the problem, so that may be the version Joe is talking about as a fork. Personally, I wouldn't mind both implementations being available as part of the core generator and libraries, with different names. Following this discussion, in my opinion I think that there are probably a few things which could be done which might make developers and apache a little happier 1. move source to a git repo - this would allow more people to 'commit' early on and send pull requests without being an official committer (although I don't know how the apache git works, github is great in that I just sign up to github, fork and go, but apache might require some more from the developer, but hey if it smooths out the process I'm for a little up front headache). 2. bug scrub - there are lots of bugs which could be closed because they are no longer valid, commmited because they don't impact binary compatibility. I'm totally willing to put in a little free time here, I think I can at least close invalid bugs if I have a jira login. 3. language/feature matrix - put together a list of all features, and a list of all languages and figure out where the gaps are. Based on gaps assign a stability to each. So I think probably the main features are serialization (can the language serialize/deserialize thrift), client library available, server type(s) available. I'm sure there are lots more, but I bet its still enough to have in an html table. 4. more committers - since thrift has so many language represented, and its literally impossible for any one or two or three people to be familiar with all of them, maybe you should shoot for one to two committers/maintainers per language. If no one is willing to step forward to maintain a language, support should be dropped (either completely by removing the code, or just receiving the lower mark in the compatibility matrix). This is not to say that because someone is a maintainer of a particular language bindings they should not take interest in the other work going on, but it should put more people in the room, so that hopefully you never have things linger for overly long. These are just my opinions, but just to give you context, I am familiar with this type of multi-language project. I'm the original author and current maintainer of at least part of a similar system called LWES (http://www.lwes.org/). We release even less frequently than thrift (while the original was written in 1998, it's not had a wire format change since then, until recently, and that change isn't yet available in any languages), and only support a handful of languages, but its given me some experience with maintaining backward compatibility across many releases over a large period of time. -Anthony On Mon, Aug 16, 2010 at 09:02:00AM -0700, Kevin Clark wrote: > On Aug 16, 2010, at 7:32 AM, Bryan Duxbury <br...@rapleaf.com> wrote: > > > On Sun, Aug 15, 2010 at 8:52 PM, Joe Schaefer <joe_schae...@yahoo.com>wrote: > > > >> Why not simply make that person a committer and let them hack on > >> trunk from the start? > >> > > > > I could agree with this in principle, but I think that there is a practical > > reason to do otherwise. In my experience, even once you've got a solid vote > > done for a new committer, you end up waiting for weeks for action to be > > taken. > > > > Would it be possible for us to allow anyone access to the /branches dir in > > our SVN repo? Then, the de facto way for experimental stuff to happen would > > be to cut a branch and get to work. > > Sorry to prod at a long dead horse, but > we'd get this behavior for free with git (and that's how most of the ruby > implementation has been developed). When the project first went into apache, > the committers discussed (and seemed to be mostly in favor of) using git. > But at the time, git was less well established and there was political > pressure to stick to SVN. Is this still a sore spot for the ASF? One of the > nice things about git is that experimentation can happen easily, and then > adding "committers" is effectively just adding the right to merge to trunk. I > suppose the danger is adding confusion to what the mainline is, but that > seems solvable. > > Kevin Clark > http://glu.ttono.us -- ------------------------------------------------------------------------ Anthony Molinaro <antho...@alumni.caltech.edu>
