From owner-svn-doc-projects@FreeBSD.ORG Wed Jan 30 19:56:10 2013 Return-Path: Delivered-To: svn-doc-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3AE8C78; Wed, 30 Jan 2013 19:56:10 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 5900E1C0; Wed, 30 Jan 2013 19:56:10 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 81DCC14D250B; Wed, 30 Jan 2013 20:56:08 +0100 (CET) X-Virus-Scanned: amavisd-new at !change-mydomain-variable!.example.com Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VUsCH5NCWojR; Wed, 30 Jan 2013 20:56:07 +0100 (CET) Received: from [192.168.1.100] (5403A6BE.catv.pool.telekom.hu [84.3.166.190]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 8FBB014D2410; Wed, 30 Jan 2013 20:56:07 +0100 (CET) Message-ID: <51097ADA.6050405@FreeBSD.org> Date: Wed, 30 Jan 2013 20:56:10 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: bcr@FreeBSD.org Subject: Re: svn commit: r40831 - in projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook: . preface References: <201301301901.r0UJ1YY6051367@svn.freebsd.org> <51096FC6.2000205@FreeBSD.org> <510977F0.2040106@FreeBSD.org> In-Reply-To: <510977F0.2040106@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-doc-projects@FreeBSD.org, doc-committers@FreeBSD.org X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 19:56:10 -0000 Em 30-01-2013 20:43, Benedict Reuschling escreveu: > Well, there is the WITH_PGPKEYS variable that just uses the > fingerprints for the print version. I could revert the above change, > no problem. > > But what about other chapters? I'm working on removing the 8.x install > chapter in that branch since the print edition will only cover 9.x. > There are still many links to the old install chapter in many parts of > the handbook. I planned to update them all to point to the bsdinstall > chapter. However, it might make sense (not just for this chapter) to > just keep links to old chapters in the online version that are removed > in the print edition. I don't know how difficult it would be to add > such a profiling attribute to every such link, but I guess it would be. > > I'm in favour of a single source solution, especially for merges back > to the online version. Right now, we try to put all changes that make > sense to both head and the book branch. However, there are going to be > changes (like deleting non-9.x content) that will be made to the book > branch sooner while keeping it for the online handbook. Of course this > makes merging difficult later on. But my view on this is that at one > point the print edition will become the new online version of the > handbook, so everything that we delete now for the book will also be > deleted for the online edition. The PGPkeys chapter can be reactivated > easier than other changes. But I think we should discuss this now > before both the branch and the online edition drift further apart. > > I don't have a problem to revert the above change, though if that is > the consensus and a solution can be found that is easier to merge. It would be very easy, practically just putting an attribute to the varlistentry and the pgpkeys sect1, something like edition="online". I think we should think of future print editions and benefit from this tidying that we are doing now to make the infrastructure capable of dealing with this. If we maintain two branches and de- and reactivate things, it can easily lead to wasting manpower and forgetting things like post cleanup and putting things back to their places. I'm working on some serious changes towards real XML toolset in a branch and it is very easy to add a custom profiling attribute like edition. For the meantime to avoid deferring the cleanup work on the content, you could use an existing attribute, like condition="online" or condition="print". Later on we can go back and refine things. Any thoughts from others? Gabor