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

[Ceri Davies]

On Mon, Dec 06, 2004 at 07:12:44PM +0000, Nik Clayton wrote:
> 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?

I agree with everything you said.  It sucks, but it isn't the end of the
world.  If it's trodden on work that you had outstanding, then it's nice
if committer A offers to help merge the changes.  However, I also think
that this is the kind of thing that your parents teach you, and we don't
need rules for that here.

Ceri
-- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.			  -- Einstein (attrib.)
-------------- 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/013eebdc/attachment.sig>