Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Mar 2000 15:10:52 +0200
From:      Neil Blakey-Milner <nbm@mithrandr.moria.org>
To:        Alexey Zelkin <phantom@FreeBSD.org>
Cc:        nik@FreeBSD.org, doc@FreeBSD.org
Subject:   Re: doc/ tree tagging
Message-ID:  <20000318151052.A93790@mithrandr.moria.org>
In-Reply-To: <20000318120027.A9870@scorpion.crimea.ua>
References:  <20000318120027.A9870@scorpion.crimea.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat 2000-03-18 (12:00), Alexey Zelkin wrote:
> I remember about attempt of resolving of this problem by creation
> of new sgml entities, but it looks little junkly for me. We'll just
> create more problems with tracking of documentation for all branches
> in that way, IMHO. And add more junk to SGML sources :(

Count me against branching the CVS tree for doc/ to the extent I
probably won't work on the non-latest version if this happens.

It doesn't make sense to have two versions of the documents in our
tree, since we'll have a scary split of changes that apply to both
branches, or just one branch, and then changes between branches
would get out of sync where something previously applied to one
branch differently, and where the new change applies to both
branches.  It'll make our current clean scheme very, very messy.

It's perfectly acceptable to have "Before 4.0-RELEASE, the IDE
disks were called wd, but since that time, they're now called ad".
It also lends a lot of consistency to the reading - someone looking
through the FAQ for 3.0 which doesn't mention ad at all, and suddenly
walking into it, will be confused.

Another interesting spinoff is for those who work across multiple
versions, where it makes sense to be presented with "3.0 to 3.3
has 'foo' feature disabled by default, but since 3.4, it is enabled".
Why should they read two different versions of a document, and
manually have to figure this out?

I also think it will be harder for translators to work on a split
tree, since they have to track two moving targets now instead of
one.  They can't just track one, and expect a little playing with
diff from the latest target will give them any useful result.

Neil
-- 
Neil Blakey-Milner
nbm@rucus.ru.ac.za


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000318151052.A93790>