Re: [RFC] New task: science-dataacquisition

[Andreas Tille <tillea@rki.de>]

[Move this thread to debian-custom list because it belongs here instead of
 debian-science list.]

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
> > and homepage.
>
> I particularly agree with this.

Sure.  Native English speakers are not that much impressed about
translations. ;-)

> > 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).
>
> Pretty please.

Done.

> 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[1].

... "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
  patches.)

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

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

> [1] At this point, I'm going to keep very quiet about the fact that I've
> been trying to maintain the physics task too :-).

;-)

Kind regards

      Andreas.

--
http://fam-tille.de