Tag reorganization proposal: role::*, scope::*
Enrico Zini
enrico at enricozini.org
Thu Jun 29 12:07:27 UTC 2006
Here comes role::*
role::aux:dummy - (Auxiliary) Dummy package used for upgrades
-> role::dummy
role::aux:metapackage - (Auxiliary) Dependency metapackage
-> role::metapackage
role::content:doc - (Content) Documentation
-> role::documentation
role::sw:devel-lib - (Software) Development libraries
-> role::devel-lib
role::sw:shlib - (Auxiliary) Shared library
-> role::shlib
role::sw:source - (Software) Source code
-> role::source
role::sw:plugin - (Software) Plugin
-> role::plugin
mornfall> the only problematic part left from current role is amusement
mornfall> which is more like use than role
role::sw:amusement - (Software) Games, toys and trivial amusements
-> use::entertaining (merged with gameplaying?)
enrico> uhm, actually. text was for books
enrico> which is not documentation
enrico> and not data
mornfall> the point is that it's sort of blurry
enrico> it is, but still there's a strong line somewhere there
mornfall> well, it's tags, it doesn't have to be disjoint
enrico> something could be both
mornfall> you can tag "fuzzy" cases with both tags
mornfall> and be happy :)
enrico> although one should pay attention when 'hiding all role::data packages'
enrico> one should do it only if they have no other role
role::content:data - (Auxiliary) Application-specific data
-> role::app-data
role::content:text - (Content) Books and text documents
-> role::data
[I'm sorry this IRC quotation is a bit long, as it deals with the
long-standing client/server, application/utility mess.]
mornfall> role::program
mornfall> i'm all for it :-)
[about merging role::sw:{application, client, daemon, server, utility}
into role::program]
enrico> where do we put the other distinctions that we're taking away from role?
mornfall> well, use?
enrico> client/server, app/utility
enrico> amusement goes into use, fine
mornfall> server and client too?
enrico> stripped-down-for-usability/bits-and-pieces-to-compensate ?
enrico> I think that this last one is (finally) a good description of what's a
utility
mornfall> the bits that remain after you cut the pieces that <10% users need?
enrico> yes
mornfall> where we stuff the general/special thingy/ ?
enrico> so, we have a proper line: if it covers >70% of the needs in a field,
it's an application; if it covers some of the remaning ones, it's an
utility.
enrico> We need a facet for it
enrico> it's two tags that are looking for a facet. role was a temporary home
for them
enrico> scope:: ?
mornfall> scope!
mornfall> there would be another level of scope that'd be "application
suite"... maybe
mornfall> mostly for metapackages
enrico> scope::broad, scope::specific
mornfall> better
enrico> thing is, everything in scope::broad would go in the KDE/Gnome app menu
enrico> it should be the kind of tag you build the app-installer on
enrico> oh, the fuck well: scope::application, scope::utility !
mornfall> well, okey
mornfall> and scope::suite please :-)
enrico> I like that
enrico> how about the client/server distinction?
mornfall> network::client, network::server?
enrico> it was used to tell apart mail clients from mail servers (or web,db,...
clients/servers)
enrico> Use case are:
enrico> Enrico wants to make money and looks at what services he can sell
with Debian
enrico> Enrico just got the ADSL line installed at home and looks at what
services he can access with Debian
enrico> oh, well, network::{client,server}
mornfall> for that use case, yes
enrico> cases that would fall off that one?
mornfall> only client/server apps that are typically run without network (unix
sockets)
mornfall> dbus, hal
mornfall> not too important
mornfall> i would leave it out
enrico> yes. they probably wouldn't be mainly understood as such
enrico> MySQL client/server could
enrico> normally uses sockets
enrico> can also uses TCP, true enough
mornfall> artsd, esd
mornfall> x server
mornfall> basically same thing as mysql -- usually sockets but can do tcp
enrico> X has a categorization of its own
enrico> The distinction seems to be 'audio server' / 'network audio server'
enrico> nas would be network::server, while artsd probably not
mornfall> artsd can do network, but usually doesn't
mornfall> probably same with esd
enrico> if I look for arts clients I probably won't go on the Network facet
enrico> question: where would I go?
mornfall> audio apps?
enrico> right. use::playing
enrico> works-with::audio
enrico> protocol::audio-arts
mornfall> it's more like "can output to arts" than "arts client"
mornfall> yes
mornfall> protocol is the right one
enrico> seems like what falls off usually falls on something else
enrico> k, let's move the distiction into network and handle the rest on a
case-by-case basis
mornfall> yeah
mornfall> sounds about right
role::sw:application - (Software) Applications and interactive, featureful software
-> use::program
-> scope::application
role::sw:client - (Software) Client applications
-> use::program
-> network::client (when applicable)
role::sw:daemon - (Software) Daemons and other background programs
-> use::program
-> network::server (when applicable)
role::sw:server - (Software) Servers
-> use::program
-> network::server (when applicable)
role::sw:utility
-> use::program
-> scope::utility
Plus scope::suite
And a new rule of thumb for telling applications away from utilities:
enrico> stripped-down-for-usability/bits-and-pieces-to-compensate ?
mornfall> the bits that remain after you cut the pieces that <10% users need?
enrico> so, we have a proper line: if it covers >70% of the needs in a field,
it's an application; if it covers some of the remaning ones, it's an
utility.
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: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20060629/3e995000/attachment.pgp
More information about the Debtags-devel
mailing list