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