[Bioperl-l] BioPerl Migration to Git/GitHub

[Chris Fields]

(comments interspersed below)

On May 5, 2010, at 4:27 PM, Dave Messina wrote:

>> Do we want to retain the git-SVN metadata on commits?
> 
> What are the tradeoffs with this? 
> 
> From the little reading I've done, it seems that space and clutter are the chief drawbacks, but that it's easy to strip this metadata out later. Does that jibe with your impression?

I don't really see much use for it personally, beyond retaining the SVN commit #.  


>> Not everyone has a github account.  Recent ones who I couldn't find on github: dmessina, fangly
> 
> My github account name is: DaveMessina
> 
> Do I have an @bioperl.org address? I tried sending mail to a few likely permutations without success. In any case, I added dave_messina -at- bioperl.org as an email address on my github account.

I think if you have a bioperl dev account you should have a bioperl.org set up.  That's one thing I'm not absolutely sure of.


>> Are we sticking with a single centralized repo (SVN-like)?
> 
> I am a total git novice, but it's my understanding that it's still a good idea, particularly with a big many-author project like BioPerl, to have a primary, official repo. But I'd be interested in hearing more discussion on this. We're at a good place to make large-ish changes to how we do things, I think.
> 
> 
>> Will that be github, or will github be a downstream repo to our work on dev?
> 
> My only concern with github being primary is in case something happens to github. Not likely, I know, but it seems prudent to maintain a certain amount of control over our destiny.
> 
> So I'm inclined to make dev be primary and github downstream, with the assumption that it'd trivial to abandon dev and make github primary in the future if we want.
> 
> Or would it be enough to auto-mirror to dev.open-bio.org, which could serve as a fallback in case github goes offline, temporarily or permanently?

Well, the nice thing about git is essentially everyone who pulls has a copy of the repo.  It's fairly easy to set up multiple remote repos and push to them, so one could easily just push a local one elsewhere.

We could also use alternate mirrors for github besides dev.  http://repo.or.cz/w is one example.


>> We could feasibly have github be an active, forkable repo that could be bidirectionally synced with dev, but I'm not sure of the logistics on this (this popped up before with svn migration and was rejected b/c it was considered too difficult to maintain).
> 
> Are there any git-familiar folks out there who could comment on the pros and cons of this? Perhaps some of the other Bio* projects who have switched to git could advise.
> 
> Right now, without further technical details, I think it'd be better to have one true primary just because it's less confusing and easier to manage, particularly if we're to follow a model like the one mentioned just below:

We can always start with a single repo and a read-only mirror.  If we follow the Moose policy, one could fork from either the public Moose git or github and make changes, then post them back to the main github repo for review by the devs. 


>> I would highly suggest we start working on branches for almost everything and merge over to trunk. 
>> [...]
>> I like this strategy (Mark Jensen pointed this out): http://nvie.com/git-model
> 
> Yep, that looks good to me, too.
> 
> 
> 
>> One in particular was that git allows destructive commits.  Jonathan Leto indicated we can set up specific branches that don't allow this, using commit hooks, so my guess is the master branch and release branches wouldn't allow rewinds.
> 
> We should try to make sure we have this sorted before going "live".

Would be adding a pre-commit hook to disallow this.  I'll look into it.


>> 5) Encouraging outside contributors
>> 
>> Do we want to adopt a policy similar to Moose?
> 
> Yes!
> 
> We want more people to jump in — one of the benefits of git and github is that they encourage this.
> 
> 
> 
>> 6) SVN Read/Write to GitHub
>> 
>> I can see allowing read-only svn, but write support is still experimental.  Do we want to allow that?
> 
> Read-only for sure — that seems harmless, and we want to give people lots of ways to get BioPerl.
> 
> Write — let's play with it a bit, making a few test commits to bioperl-test, and see what happens. It would be nice if we don't force everyone who contributes to BioPerl to have to switch over to git immediately. Me included. :)

Sounds good to me.


>> 7) Others?
> 
> What happens when we start splitting up bioperl into separate distros? Do we put them each into a separate repo?

Yes.

> Dave

Thanks!  

chris