[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 7223 - trunk/packages/rpm/mandrake-9.1

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-09-28 20:27:36 CEST

Files wrote:

>I take it back.
>
>This log message is the *same* set of changes that everyone got up in
>arms about previously when I didn't itemize all the changes.
>
>Now that I have and tried to give a *brief* overview of what the changes
>encompass, it is now too long.
>
>Where as my previous explanation that said everything was in flux and
>the documentation was about to change to identify everything, was
>insufficient.
>
>Demarcate the line in the sand if you please. And then cement it.
>
>I can't keep remodifying my protocol to fit the current interpretation
>of the policy on a given day.
>
>I read what it said in HACKING. I did what it said. Each time. And I got
>two very different results. Maybe that should be indicative of an issue
>in and of itself?
>
>
Yes, it is indicative of an issue. But not with the HACKING file, or
with our policies that are described there, which every other committer
seems able to follow. Here's how it's done:

    * Read the HACKING file.
    * Do an "svn log" of, oh, say the last 100 commits, to see how the
      log messages other people wrote look like.
    * Read HACKING again, correlating what you saw in the "svn log"
      output with what's written there.
    * Look at the example log messages in HACKING, figure out how
      they're similar to what you see in the "svn log" output, and how
      it's different from what you've done.

There are 68 developers with (partial) commit access and any number of
patch contributors who went through this or a similar exercise, and are
producing acceptable log messages. If you want to contribute to the
project, it's your responsibility to make the effort to understand and
follow the rules we've all agreed upon. These rules are intended to make
working on Subversion easier for everyone, they're not complex or
arbitrary, there aren't all that many of them, and IMNSHO they're very
well documented.

We can help with the initial steps towards understanding these rules and
their purpose -- and indeed, other people have spent quite a bit of
their time explaining them to you -- but your posts like the one quoted
above, where you blame these very same people for _your_ inability to
understand, do tend to start grating on the nerves a bit.

By volunteering to work on Subversion, you take on responsibility not
only for the bits that you maintain, but also for the general well-being
and quality of the project. This does not mean just conforming to the
coding or log-writing style, but includes, e.g., taking care to not
antagonize people with your posts; or, to take another example, not
reopening issues that have been discussed to death on the mailing lists
-- unless, of course, there are significant new insights to be gained.

The quality of the Subversion code and mailing lists is way above most
open source projects I know (not to mention closed source projects...),
and we want to keep it that way. If you find yourself unable to fit in,
or can't be bothered to learn the language of the community you've
joined, then please say so now.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 28 20:28:14 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.