Review of all the Debian Med debtags, and questions.

[Enrico Zini]

On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:
> On Thu, 22 Jan 2009, Enrico Zini wrote:
> > as far as software is concerned, that software may work with.  I can't
> > think of anything like that, so I'd go with "biological-sequence" at the
> > moment, and we're always in time to rename it later.
> Sounds reasonable.

On Sat, Jan 24, 2009 at 11:27:13PM +0900, Charles Plessy wrote:
> On Thu, 22 Jan 2009, Enrico Zini wrote:
> > I'm worried about is that "works-with::sequence" seems to be an unclear name
> > if we take it outside of the biology context.  Would
> > "works-with::biological-sequence" be acceptable as well?
> No problem. Let's consider renaming if there is later a request for a
> "works-with::foo-sequence" tag.

Ok. I added works-with::biological-sequence:

  Tag: works-with::biological-sequence
  Description: Biological Sequence


> On Thu, 22 Jan 2009, Enrico Zini wrote:
> > works-with::graphs would probably make more sense considering we have
> > loads of graph theory and visualisation software around.  We may fix the
> > confusion by describing the tag as "Trees and Graphs".
On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:
> Reasonable as well.
On Sat, Jan 24, 2009 at 11:27:13PM +0900, Charles Plessy wrote:
> Perfect.

Ok. Added:

  Tag: works-with::graphs
  Description: Trees and Graphs


On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:

> >> special::unmaintained
> >>   We unfortunately package some programs that are Upstream-dead, as many
> >>   other Debian packages are. Sadly, this tag could become very popular.
> > Yes.  I am planning a maint::* facet, in cooperation with Debian-QA, to
> > convey this sort of information (also, rc-buggy, fringe, obsolete-deps,
> > etc.)
> Will the rc-buggy automatically maintained by querying BTS?

That would be the idea, yes.  Basically, the idea would be to
automaticall maintain all of those: for example, obsolete-deps can be
extracted by finding all those packages that depend on a package with
section "oldlibs".


> >> works-with::temperature
> >>   We would have three candidate packages, but criticall mass would
> >>   probably attained with sensors and weather packages.
> > I see the need, but I'm looking for a better name: sensors and weather
> > packages wouldn't just measure temperature, but also pressure, light,
> > wind and whatnot.  So maybe something along the line of
> > "works-with::physical-measurements".  "works-with::measurements", even?
> > That may include benchmark tools as well, and instinctively I'd say "why
> > not?"

On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:

> Why not? ;-)

On Sat, Jan 24, 2009 at 11:27:13PM +0900, Charles Plessy wrote:

> Actually, works-with::measurements would not describe some of our candidate
> packages. We have "oligonucleotide design" applications that can either predict
> the "melting temperature" of short DNA molecules, or generate arbitrary DNA
> sequences whose melting temperature matches. Similarly, a weather forecasting
> program would works-with::temperature but not works-with::measurements. On the
> other hand, works-with::measurements would fit pondus (body weight management).
> In addition to this sensors packages perform the measure themselves, which
> would more fit "use::measuring".

use::measuring is a good idea, also good for benchmarks.  I've added it:

  Tag: use::measuring
  Description: Measuring

Regarding works-with::measurements, things get tricky.  The
oligonucleotide design example that you make, could arguably be a
works-with::biological-sequence rather than works-with::temperature.

Besides your example, I also cannot think of other software that would
work with temperature when it is not a measurement.  I could think of
some fictional ones, but they'd all end up into use::simulating instead.

There could be someone objecting to redundancy betwee use::measuring and
works-with::measurement, although I could see a tool to measure and a
separate tool to elaborate the measured data: for example, a sensors
driver and a R module to make sense of the data.

works-with::measurements / works-with::temperature seems to still be
controversial, so I'll wait before adding it until we reach some
consensus.

(pointless digression: all the weather forecast programs that I've seen
 so far, worked with more than temperature)


> >> made-of::data:examples, or role::example
> > Is it worth to separate examples from documentation?

On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:

> Sometimes examples are quite large.  At least we have 70 packages with
> the string example in the name:
> $ apt-cache search example | sed 's/ - .*//' | grep example | wc -l
> 70

On Sat, Jan 24, 2009 at 11:27:13PM +0900, Charles Plessy wrote:

> Not necessarly. In my hands however, example packages contain example data, not
> text documentation, but arguably the purpose is similar (although in addition
> it can be used to check if the program is working correctly).

Ok, added:

  Tag: role::examples
  Description: Examples

I admit that I'm still skeptical: we are probably going to have quite a
bit of role::documentation AND role::examples packages, I'm afraid.
If those end up being the majority of role::examples packages, we should
probably consider to merge the two tags again and find another tag in
another facet to mean 'examples'.


> >> use::calculating
> > Definitely needed.  "calculating" or "computing" ?

On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:

> I'd slightly tend to "computing" but no strong opinion.

On Sat, Jan 24, 2009 at 11:27:13PM +0900, Charles Plessy wrote:

> Better ask a native speaker ;)

I asked #debian-uk, and use::calculating came out, with the rationale
that 'computing' "has come to mean any information-processing done with
a computer".  So I added that:

  Tag: use::calculating
  Description: Calculating


On Fri, Jan 23, 2009 at 08:09:25AM +0100, Andreas Tille wrote:

> >> role::devel-lib and devel::library (actually, maybe the whole devel::
> >> facet could be formulated with appropriate combination of other
> >> Debtags). I have systematically used the first and ignored or even
> >> deleted the second. (I can repair this if you disagree).
> > That is redundant indeed, but still both tags make sense in their
> > facets.  My gut feeling is to just live with it, and maybe even write
> > some code to add one of the tags if the other one is present.
> To force the obvious redundancy?  You mean to make sure that different
> point of views of the people who do the packaging is penetrated to the
> proper place?  It somehow feels strange - but you have the experience
> in this field ...

Not the points of view of people doing the packaging, but the points of
view of people doing the searching.  If you're a software developer,
maybe you get a goplay custom view with all the devel::* tags in a combo
box, and you'd expect to see 'library' there.  On the other hand, if I
show a combo box with 'role::*' to filter by kind of package,
"development library" is definitely expected to be there.

Because of this, I don't know how to solve the redundancy without
breaking some useful use cases: as a consequence, I prefer to keep the
redundancy until I get better ideas.


On Sat, Jan 24, 2009 at 11:27:13PM +0900, Charles Plessy wrote:

> > > uitoolkit::xulrunner (in our case: biofox)
> > This makes a lot of sense: how many packages do we have?  iceweasel,
> > biofox, then?
> 
> Difficult question… Biofox actually performs some operations within the browser
> (like translating a DNA sequence into a protein sequence), while some other
> add-ons have a much simpler interface, which may not desserve description with
> a uitoolkit tag…

Ok, let's leave it aside for a while, although I'll keep it in mind, and
consider it as I see new packages based on xulrunner showing up.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20090125/976ce5ee/attachment.pgp