subversion access
Roy T. Fielding
and no links from the project... is that going to be fixed soon?
Or do you plan on using some other (internal) VCS?
....Roy
Kenton Varda
So the question is, is it worth maintaining a subversion repository mirroring the code if most development is occurring on the internal copy of the code, not the SVN version? I'm not really sure. If we find that a lot of non-Google people want to submit patches, then it probably makes sense to create an SVN repository to accept them. Otherwise, having the public release be in a separate repository from our internal code might just create a lot of work for me for no really good reason.
In any case, I'm open to suggestions on this.
Ryan Phillips
> This is tricky. It would be infeasible for us to move primary development
> out of our own internal repository because so much code at Google depends on
> it. Instead, I've put together scripts to allow us to integrate changes
> between the internal version and the public release, so we can accept
> patches, and any changes made internally will become available publicly in
> the future.
>
> So the question is, is it worth maintaining a subversion repository
> mirroring the code if most development is occurring on the internal copy of
> the code, not the SVN version? I'm not really sure. If we find that a lot
> of non-Google people want to submit patches, then it probably makes sense to
> create an SVN repository to accept them. Otherwise, having the public
> release be in a separate repository from our internal code might just create
> a lot of work for me for no really good reason.
>
> In any case, I'm open to suggestions on this.
there isn't a public SCM repository. This begs the question if this
library is going to be maintained and ever improved externally of
Google. If an opensource project wants any chance of getting more
people to contribute to it, then it must have a publicly available
SCM.
-Ryan
Kenton Varda
I just thought it would be cool to add C support to this library, butthere isn't a public SCM repository.
C support would be cool. You actually could just as easily do this as a separate physical project. The compiler front-end is available as a library (libprotoc). See the CommandLineInterface class:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.command_line_interface.html
So there's actually no technical advantage to being part of the Protocol Buffers project itself, and you might even prefer to be a separate project to give yourself more control. I'd be happy to put up prominent links to any project attempting to support Protocol Buffers in other languages, and help you with design issues and such. Does this sound reasonable?
This begs the question if this
library is going to be maintained and ever improved externally of
Google. If an opensource project wants any chance of getting more
people to contribute to it, then it must have a publicly available
SCM.
I admit I haven't exactly worked out how patch submissions will work. I sort of want to figure out exactly how much interest there is first. The big question is: how many people will really want to submit code back to the main project, vs. work on things that make sense as separate projects? If most people are really doing more of the latter, then there's not too much reason to maintain an SVN repository. But if a lot of people do want to work on the core project, I'll be happy to set up SVN to support that.
Either way, we'll definitely be pushing our internal changes out to the public periodically.
Gregory P. Smith
How to handle giving out write access can be worked out a bit later. For now, having a svn repository up gives people svn revision numbers to to file patches against and an easy way to merge in updates as we release them via a svn update.
If you want to maintain a google-like development model if/when we let some contributors have write access, point folks at the google C++ style guide http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml and suggest that patches are submitted to http://codereview.appspot.com/ for review before being accepted.
my 2 cents,
-gps
Ajay
that sense Kenton is probably right in his " let's wait for the
patches ".
Even when the patches do start pouring by scores :), a gwt like
incubator project would serve the purpose very well.
However, a lot of developer like the idea of a complete workspace that
automatically pulls from the version control. For that a project could
be created which seeds the repository with the tar ball. For those
developers that like this flexibility, remember that it is not
Kenton's day job to support protocol buffers, and is a 20% project. So
please use your 20% r&d time to write a script that takes a release
tar ball, expands it, and fires a gvn/svn command to commit to the
repository. I am sure the project would find not much objection to
incorporating that at the end of the process of upload.
Cheers,
Ajay
Glenn H Tarbox, PhD
> However, a lot of developer like the idea of a complete workspace that
> automatically pulls from the version control. For that a project could
> be created which seeds the repository with the tar ball. For those
> developers that like this flexibility, remember that it is not
> Kenton's day job to support protocol buffers, and is a 20% project. So
> please use your 20% r&d time to write a script that takes a release
> tar ball, expands it, and fires a gvn/svn command to commit to the
> repository. I am sure the project would find not much objection to
> incorporating that at the end of the process of upload.
IMHO, a Distributed Version Control System (DVCS) should be the only
strategy employed in general, and certainly for a new project. If the
reasons are unclear, google Git, Bzr, Hg. (Google tech talks has videos
of Linus and Schwarz on Git, but many of the concepts apply to other
DVCS)
My $.02 is that Git is the superior design. Bzr is simpler for people
early to the DVCS game, as is Hg. Hg is out because it doesn't have a
proper design for its object store and quickly degenerates for a project
of any size.
(lets keep VCS wars to a minimum here. I use them all. IMHO, there's
no contest... but this kind of thread quickly degenerates)
As time goes on, a project will emerge with Google as a participant.
But the centralized control for checkin / merge is unnecessary and
counter-productive.
There should also be a freenode IRC channel (or two - support / devel).
I would say that the Google folks have first dibs on getting this set up
but I volunteer to do the work if there's consensus.
Having spent a few hours looking through the design, and understanding
that Google uses this heavily internally, I'm pretty sure this can be
the foundation of strong, much needed FOSS project.
-glenn
Kenton Varda
Just to let you know, we're definitely going to get the code into SVN soon! How soon probably depends on how fast I can dig myself out of this mound of e-mail. :)