New tag proposals from iterating.org (1/2)

[Enrico Zini]

On Wed, Nov 08, 2006 at 08:57:48PM +0000, Justin B Rye wrote:

> > "Home Automation"
> > 	no mapping.  We need it for packages like bottlerocket and wmx10
> What have we been doing with "Section: electronics"?

We have a field::electronics.  We can consider that it suffices for home
automation, but field::electronics gives me more the idea of something
to study electronic equipment rather than of something to drive them.

To me, it fits under hardware.  Something like hardware::nerd, but
meaningful.


> > "Real Time Strategy"
> > "Turn Based Strategy"
> > 	we have game::strategy; iterating.org proposes
> > 	game::real-time-strategy.  Maybe we can have
> > 	game::strategy:real-time and game::strategy:turn-based ?
> game::strategy:* seems a better idea than game::time:*, and dividing
> RTS from turn-based makes some sense, but I'd vote for avoiding
> sub-hierarchies in sets this small.

We do have already game::rpg:rogue and game::board:chess; I just added
game::sport:racing.  Should I flatten?

WRT this realtime/turn thing, I'm a stuck deciding what to do:
strategy:realtime/turn-based is very simple; however mornfall's idea of
having it perpendicular, and thus allowing to use it, for example, for
puzzle games, is very tempting.

I can't take a decision.


> > "Event Automation Tools"
> > 	no mapping.  We need it for packages like cron, anacron,
> > 	fcron...  PROPOSED: admin::scheduling
> Only the clock-based ones?

Good point.  Something for more general "process management" (scheduling
job batches, monitoring execution and running new programs in a chain
when some predepending programs terminate...) would be neat.
Can you think of a word for it?


> > "Job Scheduling Tools"
> Non-clock-based things?  Except that all that sort of thing tends to
> be done via run-parts directories in each daemon etc, not by some
> central scheduler package.  Or maybe they mean "gato"?

For gato, I'd do with admin::the-scheduling-thing-above plus
interface::x11.


> > "Emulators"
> > 	it can be mapped to hardware::emulation
> > "Virtual User Interface Software"
> > "Virtual Machine Software"
> > 	We indeed miss categories for virtualization tools.
> > 	PROPOSED:hardware::virtualization? Or admin::virtualization?

I decide for admin::virtualization.  hardware::virtualization could just
be filed under hardware::emulator.  And if software appears to fiddle
with registers of virtualization-specific chips, we'll create
hardware::virtualization as well.


> With this and the last, if a tag is turning up in more than one of
> the "specialist use" facets, maybe it should be given a generic
> use:: tag.  Though not unless some examples turn up.

I concur.  Are you proposing use::administration?


> > "Network Monitoring"
> > 	iterating.org proposed to map to "security::ids"; it can also be
> > 	mapped to admin::monitoring, use::monitor, network::scanner,
> > 	depending on cases.  Do we need a network::monitoring?
> Well, where does bandwidth-monitoring fit?  That's the one I
> remember having trouble tagging.

I propose (but I'd like you to review this proposal before adding it)
works-with::network-traffic.  It fits bandwidth monitors, shapers,
tunnelers, firewalls...


> >   "E-Commerce Software"
> >     PROPOSAL: iterating.org proposes to add web::e-commerce

$ apt-cache search commerce
shows a number of packages to manage financial transactions and
interface with all sorts of payment systems:

  cl-tclink - Common Lisp bindings to the TrustCommerce transaction system
  ezpublish-src - CMS for e-commerce, e-publishing and intranets
  interchange - e-commerce and general HTTP database display system
  interchange-doc - Interchange Documentation
  libbusiness-onlinepayment-authorizenet-perl - AuthorizeNet backend for Business::OnlinePayment
  libbusiness-onlinepayment-payconnect-perl - PaymentOne PayConnect backend for Business::OnlinePayment
  libbusiness-onlinepayment-perl - Perl extension for online payment processing
  libbusiness-onlinepayment-tclink-perl - TrustCommerce backend for Business::OnlinePayment
  libnet-tclink-perl - Perl interface to the TrustCommerce payment gateway
  php4-spplus - Secured payment system of the Caisse d'Epargne (French bank)
  php4-tclink - TrustCommerce TCLink module for php4
  python-tclink - TrustCommerce credit card processing for Python [dummy package]

Indeed web::commerce seems to fit, but these are generic tools that need
not necessarily be used by web applications.

devel::commerce is far too specific for devel, though.

Ok if I just file them under web::commerce at the moment?


> >   "Conferencing Applications"
> >     "apt-cache search conference" shows various results, so we need a
> >     tag.  Problem: I don't know in which facet we should file it.
> It makes me wonder if we should have had a comms:: (?) facet instead
> of mail::, with tags for smtp, nntp, hamradio, irc, im, voip etc.
> Probably too late now.

I like the idea of a communication facet to encompass the current mail
one.  I don't like 'comms' (sounds like modems) and communication is too
long.  But once we get a name, I think the rest of the merge will follow
quickly.


> >     "Video Codecs" -> "video::codes"
> That's role::shared-lib (cf "The Theora Video Compression Codec", ie
> libtheora0).

I wouldn't mind something specific, when libraries are used as plugins.
The idea is that normally you want to hide libraries, but in case of
codecs you want to show them.  Granted, we do have role::plugin, and
with mornfall we already decided to hide based on (role::library &&
!role::plugin).

However, I can see myself looking for all available codecs (for video,
VoIP, audio) to install, with the hope that in so doing, I'll be able to
access whatever multimedia Internet will throw at them.

I do miss a place for put codec.  But, but:

> >     But then animation would fit into video as well.  I'm a bit
> >     confused, and I'm wondering if we shouldn't pack everything
> >     (including the current sound::* facet) together into some
> >     multimedia::* facet.
> I was in favour of replacing "Section: sound" with "Section:
> multimedia" before I ever heard of debtags, so you'll hear no
> arguments from me against (multi)media::audio, ::video, ::image,
> ::3d... other than arguments against then adding duplicated
> media::*:editing tags, that is. 

This would nicely fit media::codec as well.  I like the idea.
media::streaming, too.  Would you like to plan the new media::* facet
and the merge with sound::?


> >  * "Office & Business"
[...]
> Generally speaking this does sound good.

I forked it out to start its own thread.


> I have in the past thought about suggesting that we needed an
> admin::recovery (or ::rescue) more than an admin::forensics;
> "forensics" tends to be a sort of recovery + security combo.

We can split admin::forensics into admin::recovery and
security::forensics.  Does it sound good?


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: 307 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20061116/e996a2de/attachment-0001.pgp