Codebases and the IVOA

[Tim Jenness]

On Feb 14, 2014, at 08:01 , Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

> Dear IVOA members,
> 
>  [TL;DR: Should there be an IVOA-controlled codebase? answers to apps list]
> 

I hate TL;DR because it leads to me replying to that and then realizing that there is more to say.

I think it depends on what you mean by controlled. An organized place to work is different from control and oversight.


> 
> * Is it desirable for the IVOA to operate one or more central codebases?
>      - What would they look like in terms of curation?

what does “curation” mean in this regard? Vast numbers of people checking code for compliance and preparing officially blessed IVOA releases? 


>      - What would be the pros and cons for (a) contributors (b) users?

Users go to one place and see all the code. It doesn’t have to be in a single repository though.


>      - Are there different answers for different types of software:
>           client-side/server-side; different languages?

Astropy is working because of the steadfast adherence to “pure python"

>      - Are IVOA members prepared to supply the (significant) effort
>           involved in curation?
>      - Are contributors willing to cede control to the curators?

I don’t think that is the way it should work. People who contribute to a project on github don’t cede control to anyone. They are part of the team and the copyright would tend to be retained by their institution. I don’t think you are proposing a free software foundation approach where all authors hand over copyright to the IVOA?


>      - How would we handle decisions about curation policy and
>           who's in charge?

The person in charge is the person who is willing to put in the most work. Why isn’t this like any other open source project? Someone will have to volunteer to do releases.


Using Github language, having an IVOA organization which hosts repositories for all the IVOA blessed packages would seem to be a good thing. The astropy scheme of bringing many packages together into a single distribution might be suitable although that would need some thought on which packages are really related and who is actually going to babysit releases (and you could make use of submodules where the umbrella repository doesn’t have much code in it but brings versions together for release).

If everyone switches to git then you could have the best of both worlds where people still have local control of development but the organization includes a mirror of the repository. I think local control is over-rated though as I imagine that a Github style scheme would encourage more people to contribute and just because the repository is in a central location doesn’t mean that everyone gets write access.


> * Should the IVOA (or parts of it) draw up policy or best practice
>   on code development?

You could try but it’s probably a waste of time. The policy can be enforced at the commit level where people get push access if they are trusted to keep the code in a good state. Pull requests would not be accepted if they are obviously against current code style.


>      - Encouragement to use particular third-party codebases
>           (e.g. Astropy)?

In python land it is probably true that an influx of VO people into the astropy community would be a good thing and would provide a sense that astropy is bigger than STScI (which I think is what they want as well)

>      - Encouragement to use particular technologies (e.g. github)?

I think the github model has proven itself to be a great way of bringing people together. The git+fork+pull request scheme also makes it easy for people to contribute without having direct access to the repository and gives an organized model for this activity that makes it easier to track than a hopeful email of a patch to a mailing list.


>      - List of required engineering practices for IVOA endorsement?
> 
> * How should we be interacting with existing codebases?
>      - Astropy: should IVOA-wide contributions to AstroPy be via PyVO,
>           or separately for individual items?  Or not at all?
>      - others?

pyvo is a good name. 

— 
Tim Jenness