[Neurodebian-devel] How can Blends techniques be adapted to NeuroDebian

[Michael Hanke]

Hi Andreas,

and thanks for bringing up this topic.

On Sun, Jul 22, 2012 at 12:10:04AM +0200, Andreas Tille wrote:
<big snip>
> All three facts (NeuroDebian qualifies as Blend, cherry picking from
> Blends stuff is ineffective and it will finally not work any more) seem
> to indicate that we should probably try some other approach.  My
> suggestion would be that NeuroDebian would actually start using tasks as
> other Blends.  I'm aware that inside NeuroDebian some more interesting
> stuff was invented which is not available in the usual Blends
> techniques.  On the other hand the development inside NeuroDebian sounds
> quite interesting for other Blends as well - from my perspective a
> perfect situation to join forces and implement the needed things for
> every Blend on the basis of the Blends sources of information.
> 
> In any case it would help drastically if the NeuroDebian team would be a
> bit more verbose about what is need (I somehow learned by chance that my
> plan to reduce redundant information from the tasks files would spoil
> NeuroDebians way to obtain data) and what should be approached.

I do not necessarily agree with all your arguments, but I think the
conclusions are, nevertheless, exactly right.

Before we dive into the discussion let me put a little disclaimer at the
start, so we do not discuss the wrong things: We are trying hard not the
special-case NeuroDebian. We want to do as little as possible to make
NeuroDebian happening and we do not want anybody having to do anything
special for NeuroDebian. We want to reuse existing
information/infrastructure/packages as much as possible.  Any deviation
of the present status from these goals is due do lack of time/manpower
;-)

So what do we want? Or actually, it would be more efficient to ask what
makes NeuroDebian different from other blends, because most aspects are
shared.

1. We have a dedicated repository (with a number of mirrors) where we ship
   packages for a current total of 11 Debian/Ubuntu releases. On a
   web page for a specific package we advertise for what release a
   packages is available. We cannot limit us to just Debian proper +
   backports.

2. Our website is not just package-centered. The blends pages are mostly
   lists of packages (with TODOs, and additional information being
   closely associated with particular packages). These listings are IMHO
   superior to what we have. However, in addition we have a blog, pages related
   to our virtual machine image, a number of pages describing ongoing or
   planned projects, derivatives information, and testimonials -- all
   generated from various source, but appearing in a consistent look and
   feel, with full text search. Finally, any page of our "portal" has a
   comment section where people can praise/complain/provide any kind of
   feedback -- and they do!

   IMHO the blends pages are targeting people that want to "get
   involved", while our website is primarily targeting users. Including
   many first-time linux users that have no idea of most of the basic
   concepts of a distribution are. Compare

   http://debian-med.alioth.debian.org

   to

   http://neuro.debian.net

   to see what I mean.

3. Cross-references with nitrc.org. NITRC is the main portal for
   neuroimaging software. We query their database for popularity
   stats and maintain information on packages in NeuroDebian on NITRC.

The amount of information that we need to maintain separately to be able
to do this is very minimal. We get it from UDD (via DDE) and from
taskfiles -- so it is not true that we aren't using task file. Actually,
the only information not contained in UDD or taskfiles (that is not specific
to technicalities our repository setup) are 22 key/value pairs stored in
our source code. This is our overhead.  However, the way in which we
obtain the rest from Debian-sources is convoluted and fragile -- and
always soon to be broken.

If we could have all the information that the blends framework provides
in a machine-readable format -- without having to query the UDD directly
-- we would be more than happy. If we need to maintain our "own"
taskfiles for that, so be it.

However, we have so far avoided that. We rely on the existing tasks that
are relevant for our target audience (e.g. 'med-imaging'). When we have
stuff that doesn't fit any existing task, we create a new one (e.g.
'science-electrophysiology'). It did not, and still does not, make sense
to me to created yet another shadow set of task files just to stick the
NeuroDebian label on them.

This is why I keep asking for a tagging mechanism that better represents
the non-orthogonality of fields of application. The problems are obvious
in the current thread on splitting the imaging task on the Debian Med
list: what do we split into? what do we do with applications that can't
be assigned to any single one of the new tasks? What do we do with
packages that fit neither of the, now more specialized, new tasks?

For now, we handle the problem as: neuroscience is also about
electrophysiology, therefore NeuroDebian contains
science-electrophysiology. I do not see any advantage in duplication
information on electrophysiology packages outside this task. In the
context of meta-packages: People are looking for their bit of
neuroscience, not for NeuroDebian as a whole. But it might be that I'm
missing a key point somewhere.

Long blurb -- short summary: We would like to keep contributing our bits
to the existing projects/tasks in Debian unless there is a good reason
not to do so. We would like to be able to get all information back out
through a stable interface that allows us to generate our website with
minimal effort. Whatever gets us there is fine with me.

I'm not sure what else that is done in NeuroDebian would be of interest
to other blends. Anything beyond rich/comprehensive listings (already
mastered in the blends framework) quickly becomes very specific to
applications, domains, and individuals. But if there is something, we
should identify it and make it available.

Cheers,

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de