[ZF] Proposal: Launchpad code hosting for ZF projects; free commercial support for migration

Tres Seaver tseaver at palladion.com
Fri Feb 27 15:28:52 EST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:

> On 27 Feb 2009, at 20:05, Tres Seaver wrote:
>> Please let us separate the strands of the question here:
>>
>> 1. Should we move from SVN to a new DVCS?
> 
> Yes, that's a very good question.
> 
> I understand that Subversion is "good enough" for many people. But  
> that doesn't mean we can't improve the situation ever. Andreas' and  
> Roger's rejection of any new tool doesn't seem to be a well-founded  
> argument to me. Like Leonardo said, if we had stuck with such  
> arguments, we'd still be using CVS and the CMF Collector today. Change  
> isn't good or bad in itself, we just need to evaluate what we want  
> from it.

I haven't found the swtich the bug tracking at launchpad to be an
unmixed blessing, actually.

> For instance, I'd like to remind people of some of the really horrid  
> parts of Subversion: branching and merging. Who here finds this  
> comfortable to do (without using a tool such as sv or eazysvn)?  
> Because branching and merging is such a pain, we currently don't do it  
> often enough. Too often a major change has landed in some package's  
> trunk that was heavily debated and eventually removed or toned down.  
> With DVCS, branching and merging is a breeze because it's what they do  
> "for a living". Even long-running branches aren't much of a problem.  
> Thus, with DVCS you change your behaviour in unexpected manners (if  
> you only know SVN) because certain things simply become much easier.
> 
> There are other advantages of DVCS, but I think this one ranks pretty  
> high on my list. It's also a major argument for why you'd want the  
> central repository managed by a DVCS. Actually, I should say  
> *repositories* (plural). It's sort of a side-effect of SVN that once  
> you've set up a repository for your project, *all* the junk ends up in  
> there. We effectively have all our projects in one big repository.  
> With a DVCS that would change (each project would be its own  
> repository), allowing more fine-grained access control and much better  
> scaling.
> 
>> 2. If so, which one?  There are already folks happily using git,
>>   and bzr, and hg in our community:  I'm pretty sure there is no
>>   easy consensus among the four choices.
> 
> Four?

Staying with SVN is one of the four.

> Anyway, I think this question sounds more complicated than it  
> really is. I'm with Rocky: as an avid git lover I would still be happy  
> with either choice. Andreas might be afraid to learn a new tool, but  
> in the end they're all pretty similar. And like Gary said, bzr is the  
> one that's the most similar to SVN. Since we already use Launchpad for  
> bugtracking and we have that generous offer from Canonical, I'm  
> certainly +1 for bzr. Of course, if true, the fact that bzr has  
> serious problems on Windows would be a pretty big show-stopper for now.

Yup.

>> 3. If the developers choose bzr, should we take Canonical up on their
>>   offer?  I would vote "no" here:  I don't think the Foundation should
>>   outsource managment of the codebase, where custody of that codebase
>>   is the entire reason the Foundation exists.
> 
> Well, assuming that svn.zope.org is a rented server, the ZF is already  
> sorta outsourcing the hosting, right? I think it's just a technical  
> detail whether we have 'root' access to the machine the repository is  
> on or not. What matters is that the hosting is secure and reliable.

Not so.  Having *absolute* control over the repository is how we enforce
the "joint ownership" part of the copyright management, for instance.
If we rendted boxes from somebody out on the net, we would still be
responsible for running the repository, which is just not so if the
repositories are under launchpad.

The slightly blurred bit until almost this very moment has been that we
hadn't actually done the copyright transfer:  as of today, the agreement
is done, with only the exchange of executed documents as the final step.
 At that point, the ZF will be solely responsible, and should indeed
look at alternatives for hosting:  I'm just against the idea of *turning
over* the hosting to another entity whose interests don't necessarily
aligh with the foundation's.

> In fact, given the history about false or missing backups, I think any  
> change in the hosting situation could be an improvement. I distincly  
> remember that fairly recently, svn.zope.org had to be partially  
> restored from its mirror at svn.zope.de because there weren't  
> appropriate backups available. (This would be even less of an issue  
> with DVCS, by the way.)



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJqE0D+gerLs4ltQ4RAsxuAJ9RmWI6GeoCTM3ePyn9Qn1GmFXglACgwzKk
Op6erZjeVKjMPXdXcMBQfJc=
=vGDF
-----END PGP SIGNATURE-----


More information about the Foundation mailing list