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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20120722120726.GF6864@meiner
