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@debian.org>
Attachment:
signature.asc
Description: Digital signature