[Bioperl-l] BioPerl Migration to Git/GitHub

[Dave Messina]

> 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?


> 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.


> 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?


>  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:


> 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".



> 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. :)



> 7) Others?

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



Dave