From owner-cvs-all@FreeBSD.ORG Mon Dec 6 19:12:50 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7A3716A4CE; Mon, 6 Dec 2004 19:12:50 +0000 (GMT) Received: from jc.ngo.org.uk (jc.ngo.org.uk [69.55.225.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8177C43D6B; Mon, 6 Dec 2004 19:12:50 +0000 (GMT) (envelope-from nik@crf-consulting.co.uk) Received: from crf-consulting.co.uk (82-44-220-218.cable.ubr10.haye.blueyonder.co.uk [82.44.220.218]) by jc.ngo.org.uk (8.12.11/8.13.1) with ESMTP id iB6JCkCX016178; Mon, 6 Dec 2004 11:12:46 -0800 (PST) (envelope-from nik@crf-consulting.co.uk) Received: from clan.nothing-going-on.org (clan.nothing-going-on.org [192.168.1.20]) by crf-consulting.co.uk (8.13.1/8.12.9) with ESMTP id iB6JCjMK089025; Mon, 6 Dec 2004 19:12:45 GMT (envelope-from nik@catkin) Received: from clan.nothing-going-on.org (localhost [127.0.0.1]) iB6JCjVE074185; Mon, 6 Dec 2004 19:12:45 GMT (envelope-from nik@clan.nothing-going-on.org) Received: (from nik@localhost) by clan.nothing-going-on.org (8.13.1/8.13.1/Submit) id iB6JCj3g074184; Mon, 6 Dec 2004 19:12:45 GMT (envelope-from nik) Date: Mon, 6 Dec 2004 19:12:44 +0000 From: Nik Clayton To: Remko Lodder Message-ID: <20041206191243.GD72462@clan.nothing-going-on.org> References: <200412050014.iB50EMgA007188@repoman.freebsd.org> <41B425FB.5020601@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline In-Reply-To: <41B425FB.5020601@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Organization: FreeBSD Project cc: Murray Stokely cc: doc@FreeBSD.org cc: cvs-doc@FreeBSD.org cc: throdes@FreeBSD.org cc: cvs-all@FreeBSD.org cc: doc-committers@FreeBSD.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/handbook Makefilebook.sgml chapters.ent doc/en_US.ISO8859-1/books/handbook/firewalls Makefile chapter.sgml X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 19:12:51 -0000 --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Remko, On Mon, Dec 06, 2004 at 10:27:23AM +0100, Remko Lodder wrote: > I feel a bit passed by by this commit :(. I was preparing a split of the > chapter as i mentioned on doc@. You even replied to that and still you > took this out of my hand without asking me or so. >=20 > Makes me feel a little sad. >=20 > So i would like to hear how we all can arrange that these things will > not happen again. With the best will in the world, I don't think occurences like this are things we're ever going to completely prevent, nor do I think that it's necessarily a good idea to. First, we're never going to completely prevent it: e-mail's a fallible=20 communication's medium. All it takes is someone to not see a message=20 posted, or to delete it (either inadvertently, or with over-active spam=20 filters). And people are fallible -- I know I don't always remember the=20 ins and outs of which committer's on holiday or unavailable for extended=20 periods of time. Second, this is a collaborative project. Once there's consensus that making a particular change is a good idea it doesn't really matter who makes the change, as long as there's appropriate attribution in commit messages (which Murray didn't do, I believe, and has offered to force-commit to note this). There have certainly been instances in the past where I've kicked off the discussion about something, to discover part way through that I've no longer got the time to do any of the actual work. But a consensus emerges from the discussion, and whoever has the time (and the inclination) does the actual changes and commits. Sometimes this means that work gets 'trodden on'. If committer A makes a 'surprise' change that invalidates a bunch of work committer B has been prepating to commit, it's common courtesy for A to offer to merge their work with the changes B has prepared. And that's happened in the past. Of course, none of this is set in stone. What do others think? N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --4ZLFUWh1odzi/v6L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBtK8rk6gHZCw343URAumIAJ4yvscAdlzyXcd8Fs6Zogaas+ZOlwCfYiae Rii1eJ3EoCbnjY1Brc2VtVU= =mnfV -----END PGP SIGNATURE----- --4ZLFUWh1odzi/v6L--