From owner-cvs-doc@FreeBSD.ORG Sun Aug 17 12:57:59 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 4F5C61065674; Sun, 17 Aug 2008 12:57:59 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (pittgoth.com [205.134.163.206]) by mx1.freebsd.org (Postfix) with ESMTP id A7B278FC08; Sun, 17 Aug 2008 12:57:56 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost.fbsdsecure.org (c-68-83-213-214.hsd1.va.comcast.net [68.83.213.214]) (authenticated bits=0) by pittgoth.com (8.14.2/8.14.2) with ESMTP id m7HCi1s0070899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Aug 2008 08:44:01 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Sun, 17 Aug 2008 08:43:54 -0400 From: Tom Rhodes To: Hiroki Sato Message-Id: <20080817084354.62b56c8e.trhodes@FreeBSD.org> In-Reply-To: <20080817.204750.78468138.hrs@allbsd.org> References: <200808162142.m7GLgaAQ086124@repoman.freebsd.org> <20080817.073048.238614512.hrs@allbsd.org> <48A75B1A.7060809@FreeBSD.org> <20080817.204750.78468138.hrs@allbsd.org> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: gabor@kovesdan.org, 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: Sun, 17 Aug 2008 12:57:59 -0000 On Sun, 17 Aug 2008 20:47:50 +0900 (JST) Hiroki Sato wrote: > Gabor PALI wrote > in <48A75B1A.7060809@FreeBSD.org>: > > pg> Hiroki Sato wrote: > pg> > What is the reason why choosing not updating the article? > pg> > pg> Please, see [1] and [2], and my commits following this one [3][4]. > pg> Everybody (Remko, Joel, Gabor) I asked, supported the idea, so I felt it > pg> is time to get the job done. I take all the responsibility for them. > > Sorry, I was a bit behind the discussion because of a trip in the > last week. I am still not sure if removing them from doc is better > or not even after reading the thread. Moving all of them into www > (or doc), or having them on the both of www and doc would be a > reasonable idea, but moving only the team information into www does > not agree with the reason why we have article/contributors. > > 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. > > 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. I've honestly liked the idea of merging them for awhile now. > > 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. Since hats do not change that often, this is probably a worthwhile path to walk. -- Tom Rhodes