[AstroPy] AstroPy Digest, Vol 58, Issue 16

[Mark Sienkiewicz]

Thomas Robitaille wrote:
> Maybe this is controversial, but I think that no single institution should host or control the package (otherwise it would be as if we are working for free for that institution, who would ultimately get the credit). We should just be a collection of individuals, some working in our spare time, some funded to develop software, working towards a common open source project.


Where we stand with astrolib right now:  STScI is paying the hosting fee 
to have it stored on assembla.com.  I would have been happy to store it 
on one of our subversion servers here, but we are subject to NASA 
computer security policies that make it awkward for us to grant access 
for people who are not STScI employees.  (With Assembla, I only need 
Perry's approval.)  It is subversion because the previous repository was 
subversion, and we are using subversion for our other work at STScI.

If the community feels like this means that STScI "has control" or "gets 
credit", then it could be stored somewhere else.  That may or may not 
fix anything.  If I create a repository on github, then I have every bit 
as much control as I have if I create a repository on Assembla.

So, for example, if you create a github repository for us to move 
astrolib to, you are basically trading a circumstance where _I_ am in 
control of the repository for one where _you_ are in control of the 
repository.  i.e. No significant change, except for the name of the 
person who has the password needed to grant commit access.

Fortunately for the community, _I_ don't care who has control of the 
repository.  I'm watching over it because Perry said "get us a place to 
put astrolib".  If he says "give it to that guy", that's fine with me.


(Actually, there is one difference:  Assembla has a contractual 
obligation to provide service to me; github/sourceforge/whatever have no 
contractual obligation to you.  When we selected a hosting service, we 
thought about whether there might be a different quality of service 
between "paying customer" and "getting service for free".)


>  By using a distributed versioning system (e.g. git or hg) and a free hosting solution (neutral territory, e.g. github or mercurial) we can ensure that the project will live beyond the funding for any given institution, and the distributed aspect means that if the hosting solution goes out of business, moving to another will be easy.


In fact, a DVCS makes little difference to this case.  You can make your 
own private copy of the astrolib subversion repository at any time.  I 
keep daily backups of all my off-site subversion repositories (astrolib 
is not the only thing I have at Assembla) as part of my disaster 
recovery plan.  I know the backups are valid because my CI system checks 
out code from the backups, so the backups are routinely tested.

If Assembla disappears tomorrow, I still have a copy of everything, that 
I can load into any other hosting service.  If STScI disappears 
tomorrow, you could also have a copy that you could recover from -- all 
you have to do is maintain a local copy, which is the same thing you 
would do with the DVCS.


> For example, would there be barriers to moving the astrolib packages 
> into a new repository on e.g. GitHub?

Yes - if the new repository requires a different VCS, then some people 
will have to learn to use the new VCS.  In the case of a DVCS, there is 
a new work flow that you need to explain to potential developers.  For 
example, I could have to support both svn and git for my developers.

On the plus side, numpy is using git.  If you choose git, then I don't 
need _two_ new VCS.

On the minus side, during my last major software build, I did not 
succeed in compiling git on my linux machines.  But then, the last time 
I tried to compile subverion, it didn't work either.  The dependencies 
of both are nasty.

Mark S