On Tue, Feb 16, 2016 at 09:49:59PM +0100, Ole Streicher wrote:
> > 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.
Good to know that somebody fully agrees with the opinion I raised
frequently before. ;-)
> 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.
I know since some of the parts are in Debian Med - but this is "by
chance" since we share a common interest. If I would like to promote
NeuroDebian I would not ignore the chance to be mentioned at the Blends
entry page[1]. From a promotion point of view NeuroDebian looks rather
like a derivative than a Blend. As far as I understood Yaroslav and
Michael they somehow promote NeuroDebian also under this name in their
scientific community. I personally consider this dangerous since if the
two main propagators might change their jobs in a different direction
the stuff they invented will be orphaned. (I have seen this happen in
other derivatives frequently.)
>From a Debian centric point of view NeuroDebian is a Blend that fully
ignores existing Blends tools but rather invents their own and don't
give it the name Blend. :-)
> 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.
+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.
+1
Kind regards
Andreas.
[1] https://www.debian.org/blends/
--
http://fam-tille.de
