Re: [RFC] Debian tuning documents package
On Sun, 19 Jan 2003, Martin Schulze wrote:
> I could think of the following ways to manage such a document:
>
> 1. WikiTuning
>
> Use wiki.debian.net and let anybody contribute to the document.
> However, this would mean that this document would only be available
> on the web (afaik) and it won't be a comprehensive text but a set
> of links and text - which may not be that easy to read.
>
> 2. DDP::Debian Tuning or Debian Hints
>
> The DDP is writable by all Debian developers and maintains SGML
> files (that can include other files), is maintained via CVS, and
> is automatically exported to the Debian website. Once a general
> structure is set up, new sub-documents could be contributed as
> single files to be included into the main document (hence easily
> be moved around in the main document).
>
> 3. Debian Hints Database
>
> This would probably enable easy keyword searching and could be
> exported to the web and packages as well. However, it's more
> difficult to set up.
>
> I guess, I would opt for the second implementation idea,
While I do not know all these solutions in detail I think this is the
right way to go.
> and I would quite like set it up with Andreas.
I'd like to volunteer here but as I said - those techniques are quite
new for me.
> However, one could argue that some bits should go into the Debian FAQ
> or Debian Administrators Guide.
I see no reason to keep those facts from the knowledge base to build
outside from DAG - but I just had a flexible database in mind. This
could serve as reasonable source for DAG later on for sure.
> I don't think we are talking about
> *frequently* asked questions here, but special cases that are useful,
Yes, we talk about special cases which might be tricky and we talk about
saving administrators time to find out those tricks.
> but not that often used or required. As for the Administrators Guide,
> this one is debatable, and I agree that it may be a proper way if the
> DAG contains a section about Tuning and Integration that contains such
> small documents.
For sure - but this is no reason to start collecting this stuff before.
> I believe this would just contribute to package bloat if every such
> information would be placed into its own package.
Hmmm, I think if the number of such kind of packages will be greater
than 10 than:
a) I will be happy ;-)
b) we could perhaps find a better solution
In fact I see quite a time delay between this suggestion and realisation.
> If, however, none of the above is implemented, the best way left over
> would be to include some additional README files in the affected
> packages.
The problem is that you would have to share those readme files between
several packages.
Kind regards
Andreas.
Reply to: