Re: [RFC] New task: science-dataacquisition
- To: email@example.com
- Cc: Custom Debian Distributions <firstname.lastname@example.org>
- Subject: Re: [RFC] New task: science-dataacquisition
- From: Andreas Tille <email@example.com>
- Date: Thu, 11 Dec 2008 09:05:20 +0100 (CET)
- Message-id: <[🔎] alpine.DEB.2.00.0812110837080.10576@wr-linux02>
- In-reply-to: <firstname.lastname@example.org>
- References: <alpine.DEB.2.00.0812082225140.9193@wr-linux02> <email@example.com> <firstname.lastname@example.org> <alpine.DEB.2.00.0812090832280.18237@wr-linux02> <email@example.com> <firstname.lastname@example.org> <alpine.DEB.2.00.0812100854150.19574@wr-linux02> <email@example.com>
[Move this thread to debian-custom list because it belongs here instead of
On Thu, 11 Dec 2008, Chris Walker wrote:
the full package description on the tasks pages - and we do provide
even up to date translations. It is not only the versioning information
I particularly agree with this.
Sure. Native English speakers are not that much impressed about
The fact that until now nobody has sended me a patch
to blends-dev in my eyes is a prove that there is nobody out there who
regards a deeper structure in metapackages as important enough to spend
some time on it.
I've not yes found the time to do this - but one of these days...
Sounds like a new years intention. ;-)
Well, I admit I'm not really impressed by the URL above. IMHO what
we provide on the tasks pages is better. If you want to generate
a shortened List with only short descriptions - well, that's cheap.
Could be a simple "wishlist bug" (the webtools are not (yet) in BTS,
but I can put this on my todo list).
If you did that, and also provided a means of having subsections - by
not sorting the packages at all (currently they are alphabetical), and
having the ability to put in subheadings - not sure of an appropriate
syntax, but something along the lines of:
#heading "Condensed matter"
# subheading "Diffraction"
# Comment "Analysis and model fitting of X-ray diffraction
data. Synchrotron users please note that ..."
I'd definitely be convinced.
... "If you ... provided a means"
Well, IMHO we are stretching the debian-science list to far for this topic.
It is not me - it is a Debian Pure Blends effort. We should move the
discussion to this place. The current state is:
The tasks files contain per definition an _unordered_ _list_ of
dependencies. (OK, med-bio has some *unmaintained* structure hidden
in "Why:"-tagged comments.) Having an _unordered_ _list_ published
on the web pages just sucks - so the only automatic means for an
ordering is alphabethical.
What you want is:
Proposing a Section marker field that enables a parsing program to
detect sections (or even subsections). Document the field in the
Blends documentation. BTW, RFC822 format actually does not really
support this sectioning. It is a flat file format with paragraphs.
Each paragraph ends with a blank line. A section field which should
be valid for more than one paragraph entry is in principle a hackish
solution. I do not say that this is a real problem - but I would
like you to be aware about this. (I wonder whether I should tell
that XML would be the proper solution for your suggestion because
there were enough XML versus RFC822 flame wars - at least you will
have a hard time to convince me to change a running system. I guess
working patches would be convincing but probably no e-mails without
Once you have ironed out your proposal on the mailing list and in
the documentation start inserting these section fields in at least
50% of the existing tasks files.
Once this work is done I see that there is at least one person who
regards the problem as important enough to push me for an implementation
of this feature.
Please don't get me wrong: I do not say that your suggestion is bad.
In principle I like it. It has the side effect that the web pages
become even more important than metapackages (because they will not
reflect this new feature). This is OK, because the web pages are
even visible for the whole non-Debian world. But you are simply
competing with for instance a lot of GNUmed users who desperately are
waiting for a GNUmed server package, other Debian Med users are waiting
for updated packages in the field of imaging (BioImageSuite is not
even tackled by a Debian maintainer). So you have to compete with
the wishlist bugs of other users and convince me that your wishlist
is more important than theirs.
Maintaining a "competing" Wiki page is doing manual work for less
information with the constant danger of beeing outdated for the
small advantage of slightly more flexibility in the content and
having the chance (but not the real effect) to involce more people.
It is the extra structure that I think is useful. I've been organising
the wiki as a prototype structure useful until someone gets around to
adding this facility to the tasks files.
As I said this was well done and the job you did was really important.
What I further said is: The time is ripe for this "someone" to start
with the tasks files *now*.
You also forget that problems in the packaging (like missing Homepage
fields, broken descriptions, etc.) remain hidden and you are thus
wasting the chance for other QA features.
... and this item should not be underestimated. Once I had the web
pages ready I just became a different view on the Debian Med packages
which revealed a lot of problems - which were fixed after about half
 At this point, I'm going to keep very quiet about the fact that I've
been trying to maintain the physics task too :-).