Mailing list etiquette

Adrian Buehlmann adrian at cadifra.com
Sat Sep 8 03:39:17 CDT 2012


On 2012-09-08 05:17, Greg Ward wrote:
> On 07 September 2012, Adrian Buehlmann said:
>> When I say that your first attempt was "broken" (and it *was* thoroughly
>> broken IMO, you even left out a complete case), then this is impolite
>> and deserves name calling?
> 
> In certain contexts -- like, hackers who have been using Unix since
> before 1995 or so -- "broken" can have rather negative connotations.
>>From http://www.catb.org/jargon/html/B/broken.html:
> 
> """
> broken: adj.
> 
>     1. Not working according to design (of programs). This is the
> mainstream sense. 
> 
>     2. Improperly designed, This sense carries a more or less
> disparaging implication that the designer should have known better,
> while sense 1 doesn't necessarily assign blame. Which of senses 1 or 2
> is intended is conveyed by context and nonverbal cues. 
> 
>     3. Behaving strangely; especially (when used of people) exhibiting
> extreme depression.
> """
> 
> You probably meant sense 1, and Bryan may have interpreted it as sense
> 2. For future reference, something like "incorrect for certain inputs"
> or "misses a few corner cases" might have come across as less
> judgmental than "broken".

Well. Explanation #2 fits pretty well here with regards to "Improperly
designed".

Sending a high risk, highly complex, big, hard-to-review C patch that
has proven to be difficult to get right in a previous version by having
quite a couple of severe bugs, which will possibly render users
repositories unreadable, is certainly the wrong way to do it.

What's "improperly designed" here is the strategy on how to change the
Mercurial code base in a digestible way in order to achieve the goal of
making it faster.

> Now, everyone, take a deeeeep breath. Calm down. And remember how much
> context is lost when human interaction is reduced to 7-bit monospaced
> plain ASCII text. We're here to make the world a better place through
> distributed version control. That's all.

I now had a full night of good sleep with a lot of very deep breathes,
and I am now even more thoroughly disappointed about what Bryan wrote
(I'm referring to the name calling).

I had publicly and (IMHO) politely hinted to him that I would prefer the
hashed paths code to stay in Python by writing on this list:

On 2012-08-31 19:10, Adrian Buehlmann wrote:
> If only a very small fraction of the real-world population of paths trip
> the hashencode (and in turn hashmangle) C-functions, wouldn't it make
> sense to keep the hashmangle and hashencode functions in Python only?

And I got _no response_ to that at all. Instead he just sent a corrected
version of his big complex C patch which then passed the tests that I
hacked up in the mean time.



More information about the Mercurial-devel mailing list