| |||||||||||||
Google's project hosting serviceGoogle's project hosting servicePosted Aug 10, 2006 1:48 UTC (Thu) by ewan (subscriber, #5533)Parent article: Google's project hosting service ...source code changes that are highly specific to Google's environment will not be contributed back to the Subversion project because as Stein says, "It would not make sense...[since]... those changes would needlessly pollute the code base with no measurable benefit for others. This is no reason to keep the code secret, Google could publish it all, and leave it to the subversion developers to include it in main line or not. They don't have to take it if it's not useful, but they (or someone else) could use some or all of it. This approach takes those choices away. This says either "We don't trust you to make sensible decisions." or "This isn't our real reason, but we're going to fob you off with it."
(Log in to post comments)
Google's project hosting service Posted Aug 10, 2006 12:07 UTC (Thu) by hummassa (subscriber, #307) [Link] <AOL>I agree</AOL>But we must take into account _why_ Ggl wants to keep Bigtable proprietary... :-(
Google's project hosting service Posted Aug 14, 2006 23:21 UTC (Mon) by gstein (guest, #3612) [Link] Note that we have seven Subversion developers on staff (nine in a few weeks). We have a very good idea of what is interesting for the public codebase, and what isn't :-) It isn't that we don't trust the other folks to make the right decision, it is that we've been working with them for many years and know they won't want to commit useless code into the tree.
Seriously, when you strip out the pieces that connect into Bigtable, there isn't anything all that useful left. There wouldn't be anything to put into the main line. It would just be some code sitting there as a non-functional adjunct to the FSFS and BDB backends.
And all that said... look at the article again -- first sentence, fourth paragraph. I'd like to see if we can strip the sensitive bits and publish the rest. It may still be interesting to somebody out there. For example, by taking a different look at the atomicity requirements (as we had to for Bigtable), there are some new things that could be done. The FSFS backend basically took that approach, greatly simplifying the code relative to the BDB backend. So while we can't provide a new backend to the community, somebody might be able to build a new one based on the concepts in our Bigtable-based one (or at least, from the pieces we'd be able to publish).
|
|||||||||||||