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

[Andreas Tille]

Hi,

On Sun, Jul 22, 2012 at 02:07:41PM +0200, Michael Hanke wrote:
> 
> 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
> ;-)

:-)
My main motivation was to fix the manpower problem.  It is not that I
could just add manpower to the NeuroDebian team.  It is rather that I
consider some of that what you call "deviation" might be interesting for
other Blends as well and there might be good reasons to put this into
the general Blends framework as well.  So we could work together on the
same things.
 
> 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.

OK, that's probably a difference from other Blends but it might happen
that something which started as Blend might have similar needs.
 
> 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.

What I wanted to say in my last e-mail you can have this for free by
simply creating your own tasks files.

>    However, in addition we have a blog,

Cool, Debian Med has some external Blog as well and I personally hate
the editing interface.  I'm quite uneducated in this field and I'd
really like to enhance this situation.  Are you running some reasonable
Blog software yourself?  I'm not convinced that we need some
standardized Blog for Blends but some sharing of experiences might
not harm.

>    pages related to our virtual machine image,

Cool.  Don't you assume virtual images are no Blends topic?  There is no
standard way to handle this - but we definitely need this (urgently) and
I wonder whether some of your methods could be simply parameterized to
be useful for other Blends as well.  In Debian Med we have some code for
a live CD but it is not updated for a long time (I have never touched
this and do not know in what status this might be).

>    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.

There are also indirect derivatives also from Debian Med - we are
closely working together with BioLinux which is deriving from Ubuntu,
but they work on the packages inside Debian via Debian Med team.  So
I do not think NeuroDebian is in a singular situation.

>    Finally, any page of our "portal" has a
>    comment section where people can praise/complain/provide any kind of
>    feedback -- and they do!

I know about this.  The comment feature was requested some times but I
do not see a way how to deal with this currently.  My plan is to start a
GSoC project for next year to do an overhaul of our techniques -
collecting ideas and fixing things we really want just now does make
sense for me to be prepared once the time for the project descriptions
will come.

>    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.

Hmmm, do you think this is *intentionally* or possibly the same reason
what you said above: lack of time/manpower.  If you assume that this is
really intentional I can ensure you that this assumption is totally
wrong.  The page http://debian-med.alioth.debian.org can not even be
called a "Blends page" because it contains a lot of fixed "Debian Med"
strings and it is originated before I started writing webtools for all
Blends (to possibly attract other people joining the coding work but
failed so far).  I actually did not rewrote the page above for all
Blends because I do not consider it of high importance (in contrast of
tasks pages (user oriented) and bugs pages (developer oriented).

We really urgently need some more user friendly entry page for every
Blend but this up to now exceeded my personal time limit (and web design
skills).
 
> 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.

That's really specific.
 
> 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.

I use a more precise wording:  You are not using NeuroDebian *specific*
tasks files.

> 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.

I'm curious what kind of key/value pairs these might be and for what
purpose these are used.  I'm perfectly willing to enhance the Blends
framework to fit your needs.  As I layed out above some features you
might be lacking in the Blends framework is rather that it is incomplete
and some good ideas from NeuroDebian could be really great for others as
well.

> However, the way in which we
> obtain the rest from Debian-sources is convoluted and fragile -- and
> always soon to be broken.

This should be prevented by better communication.
 
> 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.

I'd regard this as the most straightforeward way to do this.

> 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.

I admit I do not really understand this intention.  Beeing able to
influence your set of packages sounds like an important thing to me.
One basic idea of a Blend is to define your specific set of packages.

> 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?

I admit I can not answer these question because it actually requires
your very expertise.  But this is a typical task for a Blends team and
it is not by chance that this thread was started at about the same time
when we considered splitting med-imaging.
 
> 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.

>From my perspective the design of Debian Science tasks is a bit wild
grown and there is no real visible scheme.  I have seen Debian Science
from the beginning as kind of an umbrella where at some point in time
some smaller dedicated Blends should be derived from.  This is currently
happening in some physics oriented fields and from my perspecive it
would be a perfectly reasonable thing to do to do the same with
NeuroDebian.  So having rather

    neuro-electrophysiology
    neuro-imaging
    ...

> 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.

To make my point clear:  I would rather prefer to create NeuroDebian-ish
web pages not only for NeuroDebian but for any Blend - I can really not
assume that the NeuroDebian user audience is the only one who deserves
good user oriented pages.
 
> 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.

I fail to see the specificallity of NeuroDebian applications and its
individual users.  I wonder how we could at least start with the web
pages - created according to your specification based on the information
in some NeuroDebian tasks pages.  This would be done for all other
Blends as well.

Kind regards

         Andreas.

-- 
http://fam-tille.de