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

Tue Aug 14 05:59:05 UTC 2012

Ping,

I have no idea how I could support NeuroDebian better with Blends
techniques if you do not find time for any answer.

Kind regards

       Andreas.

On Sun, Jul 22, 2012 at 11:03:55PM +0200, Andreas Tille wrote:
> 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
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-blends-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
> Archive: http://lists.debian.org/20120722210355.GE23678@an3as.eu
> 
> 

-- 
http://fam-tille.de