----- Original Message ----
> From: Aron Sogor <big...@gmail.com>
> To: thrift-dev@incubator.apache.org
> Sent: Sun, August 15, 2010 11:43:59 PM
> Subject: Re: sharing knowledge means sharing control
>
> Joe,
>
> To be clear: forks or branches for this discussion sake is the same
> thing, a copy of the source tree to demonstrate a concept. It is not a
> competition or animosity simply a practical method of doing what you
> would like to do, allow others to see the stuff, and if it is
> interesting enough the community will pick it up on it's merit. There
> is no better way to show something than to do it.
I've got no beef with that position ;-), but lemme ask a different
question. Someone is working on C support via glib, and although
there is a branch in subversion for that I don't believe I've seen
activity on it. It seems to me that that person is being asked to
develop the feature elsewhere, and only when he's "finished" will
it be admitted to trunk.
Why not simply make that person a committer and let them hack on
trunk from the start? If some change impacts the build system
for stuff outside the scope of the patch, *then* branch. And
when that work is done, merge it back into trunk and keep hacking.
Seems like a no-brainer, no? That way the full history of the work
is captured as it transpires, making review easier.
