cvs commit: doc/en_US.ISO8859-1/books/handbookMakefilebook.sgml chapter.sgml

[Remko Lodder]

Nik Clayton wrote:
Nik,

> Remko,

> 
> 
> 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.

Well, i think that people can inform, i dont care about the credits or
so, but i do care about the time that is lost when doing things double.
Luckily i read the commit message by accident that saved me a hell lot
of time and a hell lot of anger.

> 
> 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.

At least you tried then, eventhough email is indeed failable.

> 
> 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).

again i dont care about the credit. Informing is just a nice way of
saying hey, stop waisting your time, i did it for you instead of just
inserting the stuff.

> 
> 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.

Well i had the time and such but it got taken away.

> 
> 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?

For me the problem is solved. I had spoken with Murray and others.

I will just focus on the part that was the reason for bringing
me into the doc team in the first place. The Dutch documentation.

> 
> N


-- 
Kind regards,

Remko Lodder
FreeBSD (Dutch) Documentation Team