Josh Saddler | 16 Jul 2007 07:57
Picon
Favicon
Gravatar

Removing obsolete guides

I'd like to remove the obsolete guides in /doc/en/. They're all properly
marked with disclaimer="obsolete", and with the exception of
nx-guide.xml, none of them appear in list.xml. They don't work anymore
and have no business cluttering up our tree. Redirects are pointless too
for these old docs, as any links that may have existed to them elsewhere
on the net are years out of date.

Any objections?

Xavier Neys | 16 Jul 2007 09:14
Picon
Favicon

Re: Removing obsolete guides

Josh Saddler wrote:
> I'd like to remove the obsolete guides in /doc/en/. They're all properly
> marked with disclaimer="obsolete", and with the exception of
> nx-guide.xml, none of them appear in list.xml. They don't work anymore
> and have no business cluttering up our tree. Redirects are pointless too
> for these old docs, as any links that may have existed to them elsewhere
> on the net are years out of date.
> 
> Any objections?

You forgot to list the files you want to remove.

$ grep -e 'disclaimer="obsolete' *xml|grep -v redirect|cut -d: -f1|cat -b
     1  colinux-howto.xml
     2  ldap-howto.xml
     3  management-structure.xml
     4  nx-guide.xml

1 looks dead to me.

2 has two bugs assigned to it, one being a blocker, the doc is not listed in
the index

3:
"""<impo>
<brite>As of May 2005, this document is no longer valid but kept for historical
purposes.</brite>
</impo>
"""
should be clear enough
(Continue reading)

Josh Saddler | 16 Jul 2007 09:56
Picon
Favicon
Gravatar

Re: Removing obsolete guides

Xavier Neys wrote:
> Josh Saddler wrote:
>> I'd like to remove the obsolete guides in /doc/en/. They're all properly
>> marked with disclaimer="obsolete", and with the exception of
>> nx-guide.xml, none of them appear in list.xml. They don't work anymore
>> and have no business cluttering up our tree. Redirects are pointless too
>> for these old docs, as any links that may have existed to them elsewhere
>> on the net are years out of date.
>>
>> Any objections?
> 
> You forgot to list the files you want to remove.
> 
> $ grep -e 'disclaimer="obsolete' *xml|grep -v redirect|cut -d: -f1|cat -b
>      1  colinux-howto.xml
>      2  ldap-howto.xml
>      3  management-structure.xml
>      4  nx-guide.xml

Ah, so I did, thanks for the list.

> 
> 1 looks dead to me.

Yup, I'll kill this one.

> 2 has two bugs assigned to it, one being a blocker, the doc is not listed in
> the index

I'm currently trying to drum up interest in it among the devs who are
(Continue reading)

Jan Kundrát | 16 Jul 2007 10:15
Picon
Favicon

Re: Removing obsolete guides

Josh Saddler wrote:
> Any objections?

If I recall correctly, our practice was to never remove anything that we
used to document.

Cheers,
-jkt

--

-- 
cd /local/pub && more beer > /dev/mouth

Josh Saddler | 16 Jul 2007 10:59
Picon
Favicon
Gravatar

Re: Removing obsolete guides

Jan Kundrát wrote:
> Josh Saddler wrote:
>> Any objections?
> 
> If I recall correctly, our practice was to never remove anything that we
> used to document.

In the two plus years that I've been helping out with the GDP, I
personally have never heard of any such policy, nor did I find anything
in our projspace docs.

Given the 61 (and counting) dead files in viewCVS, that practice does
not seem to reflect reality. It makes sense to me to get rid of out of
date, invalid docs. As I said, CVS history is forever. :)

Xavier Neys | 16 Jul 2007 12:56
Picon
Favicon

Re: Removing obsolete guides

Josh Saddler wrote:
> Jan Kundrát wrote:
>> Josh Saddler wrote:
>>> Any objections?
>> If I recall correctly, our practice was to never remove anything that we
>> used to document.
> 
> In the two plus years that I've been helping out with the GDP, I
> personally have never heard of any such policy, nor did I find anything
> in our projspace docs.
> 
> Given the 61 (and counting) dead files in viewCVS, that practice does
> not seem to reflect reality. It makes sense to me to get rid of out of
> date, invalid docs. As I said, CVS history is forever. :)

There's dead & dead. Many of the deleted files are oopsies or files that have
been replaced by another one, moved elsewhere or integrated into the handbook.

Sure CVS keeps them all, but it's not as handy for anyone who wants to have a
peek at it for whatever reason.
Keep in mind that any removed file means a few more 404s.
We only remove the very very dead or dangerous ones, and the oopsies.

Cheers,
--

-- 
/  Xavier Neys
\_ Gentoo Documentation Project
/
/\ http://www.gentoo.org/doc/en/

(Continue reading)

Josh Saddler | 20 Jul 2007 06:39
Picon
Favicon
Gravatar

nvidia guide updates

Hey all. Just so you know, now that I've read the news about the changes
to nvidia-drivers and nvidia-legacy-drivers (from cardoe's blog
http://blog.cardoe.com/archives/2007/07/19/nvidia-drivers-updates/), I'm
rewriting the nVidia guide and other guides that mention the nvidia drivers.

The gist of it is that nvidia-legacy-drivers is going away, in favor of
an all-inclusive nvidia-drivers ebuild with versions for everything
available, including the one that used to be in -legacy. It's got a
smart new nvidia.eclass to do some autodetection so that the right
driver gets installed for your card(s).

Anyway, just letting you know that I'm working on it, so don't bother to
open bugs or poke the files (nvidia-guide.xml, dri-howto.xml,
gentoo-amd64-faq.xml). I anticipate having these finished soon.

Josh Saddler | 22 Jul 2007 09:34
Picon
Favicon
Gravatar

Re: nvidia guide updates

Josh Saddler wrote:
> Hey all. Just so you know, now that I've read the news about the changes
> to nvidia-drivers and nvidia-legacy-drivers (from cardoe's blog
> http://blog.cardoe.com/archives/2007/07/19/nvidia-drivers-updates/), I'm
> rewriting the nVidia guide and other guides that mention the nvidia drivers.
> 
> The gist of it is that nvidia-legacy-drivers is going away, in favor of
> an all-inclusive nvidia-drivers ebuild with versions for everything
> available, including the one that used to be in -legacy. It's got a
> smart new nvidia.eclass to do some autodetection so that the right
> driver gets installed for your card(s).
> 
> Anyway, just letting you know that I'm working on it, so don't bother to
> open bugs or poke the files (nvidia-guide.xml, dri-howto.xml,
> gentoo-amd64-faq.xml). I anticipate having these finished soon.

Updates are finished. Rewrote the nvidia guide and accompanying
references in other docs. We now return you to your regularly scheduled
program.

Dimitry Bradt | 23 Jul 2007 22:13
Picon
Favicon

GLEP51 (kbase): Resurrection!

Hiya fellow (GDP) Developers;

Sven and me have been talking about kbase lately, since we have both
the desire to revive that project. We're certain that this
gdp-oriented project would make all of our lives a lot easier. That's
why we're asking you for help.

We need input on how kbase should be working, since regular
implementations such as mindmeld[1], sciret[2] and others are just not
good enough for our use. That's why we need to find what we really
want; bundle all of our ideas and get to the point of writing our own
implementation, in coordination of the infrastructure project, if no
suitable alternative can be found.

The original glep[3] contains a set of requirements we need to need to
go over. One of our issues would be how the search engine should work.
At first Sven thought of having "natural language" as a requirement of
the search strings. Of course this could become inefficient or too
hard to implement. As such, this might be better off as an option
rather than a requirement.

If we're thinking about the functions of our implementation, we should
also have a thought on how we want to maintain, create, edit, delete,
etc our pages. Will we be using our GuideXML system in addition to
comments stored in a database? Or will we completely store everything
into the databases? Since each page would be maintained (perhaps
through a maintainer/herd-alike system), it would almost be a
requirement that the maintainers have absolute knowledge of GuideXML
if the topics are to be stored in GuideXML format. Perhaps we can
enhance Beacon[5] (the guideXML wysiwyg editor)(written by Anant aka
(Continue reading)

Sven Vermeulen | 27 Jul 2007 21:05
Picon
Favicon
Gravatar

Not placing /proc in /etc/fstab

Per bug #186814, Gentoo users don't have to place /proc in their
/etc/fstab anymore. The /sbin/rc script automatically mounts /proc
anyway (unless you set RC_USE_FSTAB="yes" in /etc/conf.d/rc which
isn't the default).

That said, I'd rather let this remain in /etc/fstab. First, it doesn't
hurt. Second, it might confuse users if it isn't set (particularly
sparc users who need to mount /proc/openprom but not /proc). And
third: it is not because /sbin/rc by default mounts it that we don't
have to document it anymore.

For instance, if rc suddenly started checking the content of every
partition to decide where to mount it (partitions with home
directories -> /home, partitions with application data -> /usr, etc.)
users wouldn't need to fill in /etc/fstab anymore (okay, crude and
surreal example) even though this file is very important for a Linux
system.

So I rather let this remain in the handbook. If that's okay for you
guys, I'll say so in the bug and leave it as-is.

Wkr,
  Sven Vermeulen
--

-- 
gentoo-doc <at> gentoo.org mailing list


Gmane