Re: let's etch a common way of using debtags for CDDs and beyond!
On Tue, 17 May 2005, Jonas Smedegaard wrote:
> 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)".
We should be clear about what this means if this is changed. For what
purpose does debian-edu create packages in Debian, and for what
purpose are other CDDs wanting to do this? The answer to this question
seems to be for the purpose of being able to turn a normal Debian
installation *into* a CDD by installing that package. These packages
are meta-packages whose installation via traditional package
installation means, will install all packages declared as dependencies.
Perhaps there are other purposes for having such a package in debian.
But if it were simply the conversion of a Debian system into a CDD,
how useful or often this sort of CDD vector would actually be
employed, but we should be clear here that this is what would be
removed in doing this.
> 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 makes the most sense to me. If the developer's reference talked
about tags, and suggested strongly that they be used (at least until
it becomes policy) and there were lintian/linda checks that warn
package maintainers that they are missing tags, I think many package
maintainers will add these and maintain them. Those that do not can
have a bug filed against their package. Users of a package who think
that a package should have another tag that it currently does not can
file a bug against the package requesting that tag.
> 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.
In my mind this *is* an inspiring model. It is inspiring because the
users of the logcheck package are motivated to file bugs against a
package when a log regexp is missing, so the package maintainer gets
pushed by the users to maintain these logcheck entries, and the user
is pushed by the actual use of the logcheck package. It is a very
healthy system, and I agree it should be considered as a model to
apply here.
> > - 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?
There is a similar collaborative proof-reading project called the
Distributed Proofreading Project (http://www.pgdp.net), which assists
Project Gutenberg in proofreading OCR scanned books, so that there can
be a reliable electronic copy. They complete approximately 230 books
(entire books) a month, 3 to 5 thousand pages a day. Its really a cool
project. You are given an image of scanned text, and the OCR's
rendition of that page, and you compare, very carefully, the two, and
make corrections where necessary, and then submit them. A second-level
person (who has done 50 or more first-level projects) then
double-checks your work, and then passes it on. Perhaps this is what
you are referring to?
Micah
Reply to: