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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
