Re: does Debian help detect gravitational waves?
Yaroslav Halchenko <debian@onerussian.com> writes:
>> It would be not duplicated work to arrange sensible tasks for your
>> workfield. I'm not sure what other duplication you might have in mind.
>
> we arranged them within debian med and debian science. Should have we
> arranged them as well within yet another blend? or our tasks do not
> belong to Science/Med?
>
> Anyways -- those were rhetoric questions, not intended for an answer ;)
Are they? I (being new to this) would be not sure: There are always
tasks (tasks? or packages?) that do not really belong to exactly one
blend -- many of "astro-publication" is not really astronomy related but
taken from science-publication. And astronomy-education is essentially
identical to education-astronomy ... A potential
high-energy-astrophysics task would share much with a common high energy
physics task. And so on.
In my opinion (this was, however, advocated so by Andreas :-) ) it is
about visibility: I didn't really realize that there is a neuro-debian
what-ever until this thread. And I am at the end curious why this is the
case. Even if it shares much with d-science and d-med, it would be IMO
useful to have a "NeuroDebian" entry in the blends list; just for the
case that someone like me want to know for what fields we have "special
editions". And the backports problem *is* IMO a common interest, at
least.
>> > > Right. I also find the CI tests important, and it would be great to
>> > > extend them to backports, experimental and such.
>
>> > yes -- autopkgtest CI is great but doesn't cut it for mass backporting
>> > since we don't even want to upload any package backport to distro X if
>> > we know that it is going to fail there. Thus package build time
>> > testing is necessary. and then it would indeed be great to setup a CI
>> > using autopkgtest for all the backports to guarantee that they continue
>> > working as additional backports enter the stage.
>
>> +1
>
> yeap ;)
While this is in principle correct, it misses a bit my point: Sure,
build time tests are essential for backports. However, if you backport
package A which is a dependency of B, then the build time test of A will
not test the function of B with the backported A. There is always the
danger that backported packages break installed ones. That's why I would
opt for CI tests wherever possible -- usually the build time tests are
easily rewritten to run on the installed package as well. And for Python
(which today is a large part of analysis packages), this is really
trivial.
Best
Ole
Reply to: