cvs commit: doc/en_US.ISO8859-1/books/handbook Makefilebook.sgml chapters.ent doc/en_US.ISO8859-1/books/handbook/firewalls Makefile chapter.sgml

[Nik Clayton]

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 at . You even replied to that and still you
> took this out of my hand without asking me or so.
> 
> Makes me feel a little sad.
> 
> 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 
communication's medium.  All it takes is someone to not see a message 
posted, or to delete it (either inadvertently, or with over-active spam 
filters).  And people are fallible -- I know I don't always remember the 
ins and outs of which committer's on holiday or unavailable for extended 
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
-- 
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 ---         .\._/_)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-doc/attachments/20041206/877a2e67/attachment.sig>