From owner-cvs-doc@FreeBSD.ORG Mon Aug 18 18:58:30 2008 Return-Path: Delivered-To: cvs-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08539106567C; Mon, 18 Aug 2008 18:58:30 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 740768FC1B; Mon, 18 Aug 2008 18:58:29 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 53B4A14D700E; Mon, 18 Aug 2008 20:58:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dQU4xpFBVVwS; Mon, 18 Aug 2008 20:58:25 +0200 (CEST) Received: from [89.134.207.83] (catv-5986cf53.catv.broadband.hu [89.134.207.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id E8C3214D700C; Mon, 18 Aug 2008 20:58:24 +0200 (CEST) Message-ID: <48A9C642.8030504@kovesdan.org> Date: Mon, 18 Aug 2008 20:58:10 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Hiroki Sato References: <200808162142.m7GLgaAQ086124@repoman.freebsd.org> <20080817.073048.238614512.hrs@allbsd.org> <48A75B1A.7060809@FreeBSD.org> <20080817.204750.78468138.hrs@allbsd.org> In-Reply-To: <20080817.204750.78468138.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pgj@FreeBSD.org, doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/articles/committers-guide article.sgml doc/en_US.ISO8859-1/articles/releng article.sgml doc/en_US.ISO8859-1/books/developers-handbook/policies chapter.sgml X-BeenThere: cvs-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the doc and www trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 18:58:30 -0000 > No offense and no explicit objection from me here. I am just nervous > about handling this sort of information which can be used in our > document more than once. > Yes, I agree, that would be nice to have, especially because that detailed contributors list as a single DocBook document looked well. > Gabor Kovesdan wrote > in <48A8001E.1000104@kovesdan.org>: > > ga> separately, so I think it would be complicated to implement. I think > ga> there are other overlapping parts, like &os; and the current release > ga> entities. Maybe it would make sense to separate them to a common part > ga> somehow and use it for the web and the doc? > > Yes, I think we should go for that direction somehow. And in a long > term, maybe we should merge www and doc into a single repository > (like www/en -> doc/en_US.ISO8859-1/htdocs or so) because of making > reuse of information easier. Currently www build heavily depends on > doc tree (www only build can be done but the result is not complete), > so I think the merged repository with an option for htdocs-only build > would also work without a serious problem. > Good idea. And we can have a website.ent in share/sgml, just like articles.ent and books.ent to easily pull in the necessary entities. About this I have more ideas as I've been looking at the opportunities with XML. I already have something in a local repo, but it's highly wip. I think that doc/en_US.ISO8859-1/share/sgml should only contain some "glue" .ent files, for example imho newsgroups.ent should go into doc/share/sgml so that translators can use them in an early phase of the translation or simply reuse them if there is something to reuse. > BTW, for teams/hats related information, what do you think about > adding files including who it is on per developer basis? An > experimental one for showing the concept is attached. It includes > pgpkey, hats, commit bit array, mentors, and location. Most of > member descriptions of teams/hats can be generated from the files, > and also the traditional first commit by a new committer can be > simplified. > The idea seems good, but with the DTD I have some ideas and doubts: - We have the location data in ports/astro/xearth, in this way we would introduce one more duplication - We have the birthday data in src/usr.bin/calendar, which may not be a problem as it cannot change - If someone leaves core and returns, or simply resigns his commit bit and returns the from-to attributes cannot be precise. Or maybe we could for example merge 1995-1997 and 1999-2000 as 1995-2000? - There might be a website or comment element or attribute to put personal websites or additional info (e.g. we have at least 2 deceased committers) Regards, Gabor