Yaroslav Halchenko <deb...@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
