[Debian-astro-maintainers] Contributing LIGO software to Debian

[Ole Streicher]

Hi Leo,

I am Cc:ing this to Andreas Tille in the hope that he can contribute
here a bit, and to the Debian Astro list
<debian-astro at lists.debian.org>, since this is our main discussion list.
Could you put your answers to debian-astro at lists.debian.org as well?
Debian-astro-maintainers at lists.alioth.debian.org is more for technical
packaging and quite crowded by bug reports, upload messages and such.

On 20.03.2017 21:54, Leo P. Singer wrote:
> I am part of an experiment called LIGO, Laser Interferometer
> Gravitational-wave Observatory [1], that uses laser light to detect
> and study gravitational-waves, ripples in space time produced by
> collisions of black holes. I want to offer to contribute our
> project's software stack to Debian-Astro. This would lower the
> barrier of entry for researchers and students to work with LIGO
> data.

That is really a great idea, exactly this is one of the goals of our
project!

> Our software mainly consists of LALSuite [2], a collection of several
> C and Python packages that provide tools and libraries that are
> coarsely organized by scientific topic. Our collaboration already
> generates Debian packages (as well as RPMs) to deploy our code on our
> Debian (as well as Scientific Linux) computing clusters. I am not a
> maintainer of any of these packages myself, but I am a frequent
> contributor on both the codes themselves and the Debian packaging. I
> would probably be involved in some way in actually uploading the
> packages to Debian.
> 
> I have a few questions about how to get this process started. We keep
> our Debian package source in our own public source repositories. We
> prioritize developing for the current stable Debian release because
> that is what we run on our clusters, although I have made sure that
> at the moment everything builds Lintian-clean on testing and unstable
> as well. How would this work with Debian-Astro's model? Would we need
> to have a mirror of our source code on Alioth, for example?

Debian Astro are actually a number of closely related things:

* a mailing list (debian-astro at lists.debian.org) to discuss user and
developer questions related to astronomy

* a packaging team (on alioth; with the debian-astro-maintainers list)

* a Debian Pure Blend (with a web page, tasks to ease installation etc.)

Ideally, all of these are used together. However, this is not a strict
requirement. If you want to maintain the LIGO packages yourself, this is
possible as well. But then we will lose an important feature, which is
team maintenance. For others, it is much more difficult to provide
patches for the LIGO packages, or to create and upload a bugfix if the
repository is somewhere else.

We had exactly this problem with some packages of the Neurodebian team
at the end of last year: several of their packages had RC bugs (and were
already scheduled for autoremove, so that they would be excluded from
Debian Stretch), but they didn't have the manpower to fix them. At the
end, they agreed to move the packages to the debian-science team (and
the git repository to alioth), so that we could fix them together.

This may be not so important for very specific packages, but many
required dependencies are later also used more commonly, and there we
could run into trouble.

So, you are free to maintain them yourself (and just upload to Debian),
or to to team maintenance (and *move* the development repository to
alioth), but keep that in mind, and for common packages please strongly
consider moving to team maintenance. It also helps to provide simple
patches, like test cases or journal references.

Andreas, would you add something here, or do you disagree?

What concerns the distribution (stable vs. testing/unstable): it makes
much sense to "backport" the packages once they are in testing, so that
you can provide versions for the stable release as well, as you already
started for astropy.

> On a more technical level, I wanted to ask about one particular
> package of ours, glue. It's a dependency of most of our Python
> software and provides I/O and workflow management ("glue" code). It
> conflicts with the existing python-glue package [3]. Would it be
> sufficient for us to rename our package python-logo-glue and declare
> the conflict in the control file?

That is a real problem. Technically, the  package could be Priority:
Extra and declare the conflicts; however this will prevent people from
installing your "glue" and the glueviz "glue" together. Since they both
play in the same area, this may actually decrease user experience. I
must say that am not sure if I would sponsor a conflicting "glue"
package andwould strongly recommend that you contact the glueviz
developers to resolve the conflict upstream. Wouldn't ligoglue (or
something similar) a solution also for the Python package name?

Best regards

Ole