[AstroPy] AstroPy Digest, Vol 58, Issue 16

[Matthew Turk]

Hi Tom,

On Tue, Jun 14, 2011 at 1:57 PM, Thomas Robitaille
<thomas.robitaille at gmail.com> wrote:
>> 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.
>
> Thanks for your comments on the whole version control issue! Just to check - on GitHub it is possible to have as many 'owners' as you want, and there is no single more important owner. Check out NumPy for example:
>
> https://github.com/numpy
>
> Any one of the owners can grant commit privileges to anyone else, so there is no single person in control, which may alleviate some of these worries?
>
> In any case, I don't think the repo/VCS issue is as big a deal as I made it out to be. In the end, one can always change hosting, and it's not the most important thing to worry about right now - we can always put it up to a vote when the time comes. If people are willing to participate, I don't think the choice of VCS should matter :-)

One thing I would bring up is that there have been any number of
yak-shaving discussions about rebasing and history rewriting and
dropping things from the reflog after the matplotlib, numpy, cython
and scipy projects have moved.  Hopefully AstroPy will be able to
avoid these by allowing or favoring a branchy model of development.
One thing I have noticed is that these discussions seem to happen much
more commonly with git than hg, and I'm not entirely clear on why that
is; I suspect it may just be that hg encourages one not to rewrite
history, and so the hydra-approach is more accepted.  With Enzo
specifically branchy development has been very handy.

-Matt

>
> Cheers,
> Tom
>
>>
>> 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
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>