From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 00:24:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FDEB1065675; Fri, 3 Sep 2010 00:24:16 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id CB2398FC0A; Fri, 3 Sep 2010 00:24:15 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 4DE9D40A7C; Fri, 3 Sep 2010 02:06:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id 0xe3gadJc0SC; Fri, 3 Sep 2010 02:06:30 +0200 (CEST) Received: from [192.168.1.3] (unknown [187.6.89.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id B474D40A61; Fri, 3 Sep 2010 02:06:29 +0200 (CEST) References: <20100902080219.GH64651@hoeg.nl> From: Daniel Gerzo Content-Type: text/plain; charset=us-ascii In-Reply-To: <20100902080219.GH64651@hoeg.nl> Message-Id: <45764F17-2279-4520-93D7-8F0B8BE991DE@rulez.sk> Date: Thu, 2 Sep 2010 19:54:39 -0300 To: Ed Schouten Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPod Mail 8A293) X-Mailer: iPod Mail (8A293) X-Mailman-Approved-At: Fri, 03 Sep 2010 01:14:17 +0000 Cc: "doc@freebsd.org" , "current@freebsd.org" Subject: Re: Call for Documentation Contributors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 00:24:16 -0000 I actually think there is some point in this idea. The problem is that many t= imes we just leave notes or warnings specific for given releases, which can m= any times lead to confusion (or people just don't notice) and as time goes a= nd we cut the support for given releases they get stale (e.g. We had many of= those for 5.x). We could just maintain the handbook in separate branches like we do with src= , keeping them all built online, and merge relevant things where appropriate= . This will, however, add quite a lot (for my taste) of additional work for u= s. Daniel Gerzo On 2.9.2010, at 5:02, Ed Schouten wrote: > * Mehmet Erol Sanliturk wrote: >> Please separate Handbook with respect to distributions , i.e. , maintain a= >> different Handbook for each distribution . >=20 > The problem with that is that it will cause documentation for older, but > still supported releases, to become stale. Most doc changes apply to > functionality provided by both releases, or at least functionality that > is MFC'd. >=20 > --=20 > Ed Schouten > WWW: http://80386.nl/