As someone who derives great benefit from Thrift and has advocated for it at work, but hasn't participated in the community much, here are the things that I'd love to see:
Easy Code Review Tool: Patch files are a lousy way to review code (whether sent to the mailing list or attached to a JIRA issue). Mondrian (see Rietveld: http://code.google.com/p/rietveld/) was a huge success in this regard - it made viewing changes in context, commenting on changes, and approving changes very easy. An OWNERs file made it easy to identify who would be an appropriate reviewer for a change. I understand the community at Apache works differently, so you might not have an OWNERs file or have approval required, but the ability to easily see what's changed and ask questions in-line was a big win. I'd be much more likely to review changes if could click on a link in an email sent to the mailing list and see them presented in that way - no futzing around with patch files required. I'd do it just for my own edification, like I did with Bryan's async Java client patch. One benefit of something like an OWNERs file is that you can solicit feedback from people directly (and cc the list) instead of sending to a list and hoping someone takes the initiative. Language-Specific Mailing Lists: Like most people, I'm only interested in a subset of all the languages that Thrift supports (Java, Erlang, and potentially C) - I don't have the expertise or time to read mail or review changes related to Python, C#, Lisp, etc - being able to whittle the flow of information down to languages I'm interested in would make it easier to stay on top of things - and would probably also encourage the development of smaller language-specific communities. Stable Trunk: I'm fine with people developing on branches hosted in the official repo, but I'd prefer to have a stable trunk. Like others have pointed out, a lot of us run production environments on thrift and it's nice to be able to stay current while continuing to have a reasonable level of stability. Also, I prefer to submit code when I feel like it's ready - developing on trunk in the official repo would scare me - being able to fork on GitHub and play around doesn't, because I won't affect anybody until I'm ready and someone approves my pull request (branches solve this problem as well - doesn't have to be git). Finally - I just didn't realize that more community involvement was desired. The active committers/maintainers have been doing a good job and I've been content to let them - so it's partly my fault for not making the effort to get more involved. I'll be glad to do reviews for Java or help scrub bugs with Anthony or take a stab at implementing a feature that's missing from Java now that I know that's desired. I'm very grateful for thrift and the effort that the committers have put into it, and I'm also glad to learn that more community involvement is encouraged. Joel On Mon, Aug 16, 2010 at 10:56 AM, Anthony Molinaro < antho...@alumni.caltech.edu> wrote: > 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> >
