Re: let's etch a common way of using debtags for CDDs and beyond!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17-05-2005 16:44, Holger Levsen wrote:
> In our vision a Custom Debian Distribution is built from one cdd package
> per CDD (see http://wiki.debian.net/index.cgi?CDDTool for more info on that).
> That cdd package is not maintained inside Debian but maintained by the CDD.
To clarify: While most other CDD work is best passed on to Debian, the
actual CDD package is not intended for inclusion in the official Debian
archive.
This is different from the current Skolelinux approach - the packages
base-config-skolelinux, cfengine-skolelinux, locale-config-skolelinux
and webmin-ldap-skolelinux is currently in Debian.
So I suggest changing the current definition of CDD (as described at
http://wiki.debian.net/index.cgi?CustomDebian ) from currently reading
"all extras they offer will either become part of Debian, or are
temporary workarounds" to add "except what is relevant to the CDD only
(selection of packages, unique config tweaks, custom logo and so on)".
> These group of tags ("facets") also need more work, for example there is only
> one tag called "educational" and another tag "desktop", but educational and
> desktop groups of tags ("facets") are missing.
Hmm - defining those as facets may not be necessarily: If you lack is
educational::math then it is found by combining use::learning and
field::mathematics - and if you want educational::cms-systems I
recommend instead adding field::school-management that can then be
combined with web::cms (or admin::accounting or admin::user-management
for other known relevant areas).
So I suggest: Keep the number of facets low!
> What should be covered by a policy ? For example: the namespace tags use,
I am not quite sure what is meant by "namespace" above. I guess now is
the time to suggest adopting official web ontology. See
http://www.w3.org/TR/owl-features/
(thanks to http://www.skolelinux.de/wiki/DavidWeichert for making me
aware that such thing as "web ontology" existed at all).
> common facets of tags, criterias how to decide which tags should be attached
> to packages, how to tag packages to mark them as "belonging" to a specific
> CDD, how should specific compile-time-features like ldap, ssl, kerberos, etc.
> be tagged ?
An important thing to also include in a policy is also who is ultimately
responsible for each tag.
I propose each package maintainer to be ultimately responsible for tags
of the package.
This is not as controversial it may sound: Package maintainance is also
ultimately the responsibility of each package maintainer (wether
official Debian packages or not), but were overriding package
responsibility recquires repackaging and maintainance of the forked
package, overriding tagging responsibility is much simpler to do.
> Is web::typo3::mandatory::skolelinux::$someschool a good or a bad way of
> tagging ? Or would it be better to use web::typo3::mandatory, cdd::skolelinux
> and local::$someschool ? (Don't forget cdd:skolelinux::$country...) Do we
> need/want tags like web::typo3::mandatory at all ? (Maybe we should start
> with "Best practices" and work on a policy later...)
Skolelinux-related tag are relevant only for Skolelinux, so is not
interesting for sharing amongst CDDs or adoption into Debian.
So I suggest keeping tags generic. That is, avoid Debian-centric and
CDD-centric and instead use/invent generic and reusable ways to express
needs of each CDD instead.
> http://debtags.alioth.debian.org/ has some job offerings and another
> todo-list, the jobs related to managing the tags are:
> - Find a good way to maintain the central Debian tag vocabulary (technical
> infrastructure, people in charge of it)
For inspiration look at how the package "logcheck" maintains grep
expressions of loglines of daemons for (ultimately) all packages:
Initially expressions are added by the maintainers of logcheck, but a
formal way for each package maintainer to include own expressions is
provided, and as soon as package maintainers starts maintaining their
expressions themselves the corresponding logcheck-maintained expressions
are dropped.
So I suggest to have the package debtags include (probably cleverly
cached) all tags found below /etc/debtags/tags/ with that folder
containing a file for each package, named by the package itself.
> - Discuss the idea of "Adopting" tags, that is having people who take care of
> the correctness of the list of packages associated to a given tag (which
> another point of view compared to checking that all tags associated to a
> package are correct) (Suggested by Erich Schubert)
I fail to locate it right now, but sounds like the collaborative
proof-reading process of "Den Store Danske Ordliste" (the large danish
wordlist) project may be interesting for this. Do anybody know of
english documentation of that or of similar web-collaborative projects?
If needed I can translate the documentation of DSDO...
> - Discuss the idea of "Outsourcing" the maintenance of some tags: for example
> the Gnome and KDE people could take care of maintaining the tag data related
> to Gnome and KDE.
Sounds similar to Gnome nad KDE maintaining their own Debian packages:
It is good as part of the development process that they provide testing
packages (and tagging) related to their own project, but IMHO better
that each official Debian/Ubuntu/Skolelinux/local package maintainer is
the ultimate source for official tagging.
That way, anyone can _choose_ to use the tagging of upstream (or that of
others (read: backtags.debian.net ;-) )), but the tagging of the project
(ultimately maintained by each member (read: package maintainer) of the
project) is done by the project itself.
> Now let's do it and start a discussion with the goal of defining a common set
> of rules, a policy for nameing, grouping and assigning debtags. This
> shouldn't take us (too) long as there's lots of work that needs to be done
> after that, every CDD has to define its debtag policy and we together (and
> seperated) have to define tags and facets and attach them to all the
> packages...
I believe in fact it could end up taking a long time to agree on a set
of rules.
Important to note here is that even while discussing common rules for
tagging, each CDD can sit down and implement its own tag repository -
then later those local tags may become useless but the experience in
integrating tagging into package-selection, menu-generation and other
novel uses are still valuable.
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCileXn7DbMsAkQLgRAoyHAJ9XUy8/378TyEeCKYaPaaKKHsJp5QCfWgdO
tcePM6BDb6C3VMq5ntUIHqU=
=JGXk
-----END PGP SIGNATURE-----
Reply to: