[AstroPy] AstroPy Digest, Vol 58, Issue 16

Prasanth oneaufs at gmail.com
Wed Jun 15 00:42:54 EDT 2011


> 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.
> The developers at nvie.com have suggested a branching model, available at
http://goo.gl/QI0uv, that seems to have become quite popular. If we like the
idea that there is a core group of 3-4 developers who have write access to
the repository that contains the release software, then this kind of model
will be something to consider.

One benefit of having something like Github, is that each contributor can
work in their on small repository, and send pull requests to the main
repository. The main repository can then cater to the audience that would
like to have a "kitchen-sink included" distribution, while experienced
developers can pick and choose from the smaller ones. I am not saying that a
"kitchen-sink included" approach should be the choice, but whatever the
final main astropy/astrolib distribution is. It will be the job of the core
developers to make sure that the code submitted from individual developers
meet the necessary criteria for inclusion into the main repository.

In fact the individual developers themselves can have two or more branches
where one branch would be in a form that is acceptable to the main
repository, while the other would be liked by people who want finer control.
But this may raise its own problems, which is ok as long as we advertise the
possible issues upfront.

As long as the developer refrains from history rewrites in the branch from
which the main repository is asked to pull from, the conflicts can
be manageable(?).

Depending on the complexity of the individual project, some may need to work
more closely with the main repository than others. But this would still be
very flexible.

It may be too early for this kind of specifics, but I thought it would be
nice to have something concrete in addition to the necessarily general


> >
> > 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
> >
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20110615/8e4eb64e/attachment.html>

More information about the AstroPy mailing list