Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?

ruby-talk
21

I suspect it is more a matter of no tact and no shying away from saying
things in a way that might be construed as racist rather than actually
racist. Notice that:

1. He refers to the problem as a Japanese cultural issue because,
apparently, he has been told that the way things are managed is a choice
specifically grounded in Japanese culture -- not (as far as I can tell)
because he thinks Japanese people are incapable of doing better due to
some racial constraint.

2. He refers to a perceived need to communicate in English as a "lingua
franca" of international open source software development, despite the
fact his own name suggests to me that perhaps English is not his native
language. This suggests to me that he is probably speaking of a "de
facto standard" language for communication, as he perceives things,
rather than xenophobic linguistic imperialism or something like that.

I agree that the correct response should have been to ask someone for
translation assistance and perhaps suggest that the maintainer in
question should ensure that he can respond in English to people who
communicate with him in English in his capacity as a maintainer, even if
that means co-ordinating such responses with someone else who knows
English well. I do not agree that we should have hair-triggers when it
comes to resorting to accusations of actual racism.

If he *is* being genuinely racist, I don't know that I have any
objections to asking him to leave the Ruby community (though that is not
necessarily the same thing as asking him to stop using Ruby). I just
don't think the evidence necessarily indicates genuine racism. It only
indicates a huge attitude problem, in my estimation.

···

On Fri, May 02, 2014 at 03:57:15PM -0700, Eric Hodel wrote:

On 2 May 2014, at 15:49, Ricky Ng <dummey@gmail.com> wrote:
> Or Rubyists are unable to understand the frustration that a language
> barrier has created on an important module? And thus resort to
> labeling it as a racists rant with remarks about leaving the
> community instead of attempting to understand the issue at hand
> which is that Felipe cannot get a straightforward response about why
> his proposed changes were rejected?

I fully understand the frustration. I’ve been working with the other
ruby committers for over a decade and have been one for nearly half
that time. I have personally felt these feelings of frustration
numerous times.

Saying “use English and western cultural norms, Japanese ones are not
good enough” is racist.

tadf went to great lengths in #7445 to describe his reasoning for
rejection in the language he speaks well. If that isn’t good enough
for Felipe he could have asked politely for translation assistance.
Instead we have this racist rant.

I really don’t want to fix bugs for people that say such things and
don’t want to welcome them into my community.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

22

Sure it doesn't excuse that, but I think you should be more concerned
about the health of the project rather than how a particular small
contributor communicates himself.

···

On Fri, May 2, 2014 at 5:54 PM, Brandon Weaver <keystonelemur@gmail.com> wrote:

Perhaps the response was less than straightforward, but that does not excuse
the lack of tact in addressing it. There are far more civil ways to raise a
concern than this

--
Felipe Contreras

23

>So, if both "%s" "%z" are "undefined" should Ruby ignore them? No, if
>they have an understood meaning outside of POSIX, mainly GNU libc, it
>makes sense for Ruby to support them, specially when it doesn't cause
>any conflict to do that, and they are useful.
>
>So how about "%s %z"? Well, it does work correctly in GNU libc (see
>program below), so if we follow GNU libc for "%s", and for "%z", why
>not for "%s %z"?

The behavior of strptime(3) is full of ad-hoc matching, and often
misbehave. In the past, Tadayoshi hesitated to support that ugly
behavior and we took long time to persuade him (to support most common
cases). This is only my guess, but he might feel this could be a
start of bunch of requests for supporting every corner bit of
strptime(3) behavior of the specific implementation (namely glibc).

Ah, the good old slippery slope fallacy[1]. How about we concentrate
on the issue at hand and not worry about hypothetical futures that
won't happen?

Moreover, if you accept that we follow glibc for "%s" and "%z", why
would you argue that it's wrong to follow what glibc does for "%s %z"?

Remember, in the C specification, struct tm does not have a member to
preserve timezone (although glibc has). Your expectation to Time and
DateTime can only meet on some but not all platforms.

This doesn't follow. Neither Time nor DateTime use the system's
strptime(3), so it's up to us to determine the behavior we want of
these which would work on all systems.

And since you already accepted "%s" is not POSIX, it follows that the
expectation of strptime("%s") might not be met either on some
platforms, yet it's part of both Time and DateTime already.

And why are you ignoring my other arguments?

1) DateTime.strftime with "%s %z" is *already* using the tz instead of UTC
2) Time.strptime with "%s %z" is *already* using the tz (and Time.strftime)

Why would you create this inconsistency? Even if you ignore the
behavior of glibc, Ruby MRI is *already* using the timezone correctly
for "%s %z" in several places. I would really like an answer to that.

  DateTime.parse("1970-01-01 01:00 +0100").strftime("%s %z")
  => "0 +0100"

Considering that, compatibility to other implementations (on glibc) is
not useful to persuade him, but showing importance to support "%s %z"
universally in the real-world use-case might be.

Why are we talking about persuading him? If we, the project, agree
that this is the way to go, why would the opinion of a single person
hold hostage the change we all agree is right?

And I'm still waiting for a single reason why the patch should not be
applied. What problem could it possibly create to anyone?

Cheers.

[1] Slippery slope - Wikipedia

···

On Sat, May 3, 2014 at 12:56 AM, Yukihiro Matsumoto <matz@ruby.or.jp> wrote:

In message "Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?" > on Fri, 2 May 2014 22:33:21 -0500, Felipe Contreras <felipe.contreras@gmail.com> writes:

--
Felipe Contreras

24

Indeed, the language is getting better, but not as much as it could,
and not as fast as it could. Specially considering the huge amount of
people that stay away from Ruby MRI where they could be contributing
to it.

But by getting better I didn't mean the language itself, I meant the
popularity of it.

···

On Sat, May 3, 2014 at 1:36 PM, Carlo E. Prelz <fluido@fluido.as> wrote:

        Subject: Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?
        Date: sab 03 mag 14 01:23:52 -0500

Quoting Felipe Contreras (felipe.contreras@gmail.com):

It's because of trivial issues like this that I'm starting to realize
why it's never going to get any better.

It is constantly getting better. It may not be getting more *popular*
(although I have no hard data on this). The two things are quite
apart. Anyway, I for one am very proud of how the development of my
favorite language is being carried on. Many thanks + arigato to all of
you out there.

--
Felipe Contreras

25

1. He refers to the problem as a Japanese cultural issue because,
apparently, he has been told that the way things are managed is a choice
specifically grounded in Japanese culture -- not (as far as I can tell)
because he thinks Japanese people are incapable of doing better due to
some racial constraint.

That's right. I know very capable Japanese programmers, and I know no
race could be impeded in anyway from being good programmers.

2. He refers to a perceived need to communicate in English as a "lingua
franca" of international open source software development, despite the
fact his own name suggests to me that perhaps English is not his native
language. This suggests to me that he is probably speaking of a "de
facto standard" language for communication, as he perceives things,
rather than xenophobic linguistic imperialism or something like that.

Right again. My first language is Spanish, I had to learn English like
the vast majority of the people in the world that want to engage in
international communities.

The problem is not the race, the problem is the culture (which is not
specific to any race).

In this particular case reason triumphed, so that's good, but I feel
the issue shouldn't have happened in the first place, which suggest
some deeper issue. Hopefully issues like this don't happen again, but
if they do, well, we'd know the answer.

Cheers.

···

On Mon, May 5, 2014 at 11:16 AM, Chad Perrin <code@apotheon.net> wrote:

--
Felipe Contreras

26

I'm equally concerned with both. Never underestimate the impact that the
attitude of contributors can have on a project.

Instead, seek to find understanding. It seems you still do not understand
the point.

···

On Fri, May 2, 2014 at 9:05 PM, Felipe Contreras <felipe.contreras@gmail.com > wrote:

On Fri, May 2, 2014 at 5:54 PM, Brandon Weaver <keystonelemur@gmail.com> > wrote:
> Perhaps the response was less than straightforward, but that does not
excuse
> the lack of tact in addressing it. There are far more civil ways to
raise a
> concern than this

Sure it doesn't excuse that, but I think you should be more concerned
about the health of the project rather than how a particular small
contributor communicates himself.

--
Felipe Contreras

27

Hello,

And why are you ignoring my other arguments?

1) DateTime.strftime with "%s %z" is *already* using the tz instead of UTC
2) Time.strptime with "%s %z" is *already* using the tz (and Time.strftime)

Why would you create this inconsistency? Even if you ignore the
behavior of glibc, Ruby MRI is *already* using the timezone correctly
for "%s %z" in several places. I would really like an answer to that.

DateTime.parse("1970-01-01 01:00 +0100").strftime("%s %z")
=> "0 +0100"

According to the discussion in Japanese, formatting (output) is OK,
but parsing is not. For example, "Sat May 3 00:00:00 2014" can be
parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
because it contains contradicting information. Hence at least some
part of the original string should be ignored. That wouldn't happen
in output. According to Tadayoshi's opinion, time_t (%s)
fundamentally comes without timezone information from its definition,
so that the combination is meaningless, thus ignored.

I know unlike day of the week, timezone information does not
contradict with time_t. They are independent. I don't think his
opinion is universal truth, but at least I respect his opinion.
When our opinions differ, I try to persuade.

So please tell me, why do you want to parse date strings in form of
"%s %z"? Just for consistency? Or something git related? If git
somehow uses this kind of strings pretty often, that fact might be a
good reason to support. Otherwise you can always use _strptime()
method, which parses and retrieves as much information it finds, as
Tadayoshi stated before.

Why are we talking about persuading him? If we, the project, agree
that this is the way to go, why would the opinion of a single person
hold hostage the change we all agree is right?

Because whole date/datetime is his masterpiece. He designed and
implemented it from scratch. He has been maintained it for long time.
I don't want to force him in any way just because his work is bundled
with Ruby. Just like I don't want to be forced to do anything just
because of Ruby is a part of something, e.g. a Linux distribution.

Once I asked him for permission to bundle his work with Ruby, but I
didn't take it away from him. I don't want to lose him, nor date
subsystem, his long time effort and huge contribution to the Ruby
world, just because our opinion is different in corner cases.

              matz.

···

In message "Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?" on Sat, 3 May 2014 01:32:09 -0500, Felipe Contreras <felipe.contreras@gmail.com> writes:

28

The problem is not the race, the problem is the culture (which is not
specific to any race).

But who decides which is the "right" culture that we should adhere to?
Do we automatically inherit it with the language English?

In this particular case reason triumphed, so that's good, but I feel
the issue shouldn't have happened in the first place, which suggest
some deeper issue. Hopefully issues like this don't happen again, but
if they do, well, we'd know the answer.

Even if the original issue should not have come up I - as a bystander
in this case - also feel that your reaction should not have happened.
There are ways to air frustration and even anger without resorting to
four letter terms or name calling. In my experience a different style
of communication is much more helpful in resolving conflicts and
reaching goals. Another effect of some styles of communication is that
people might start wondering whether it is really that important to
the person to get her problem resolved.

Kind regards

robert

···

On Mon, May 5, 2014 at 8:36 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

--
[guy, jim].each {|him| remember.him do |as, often| as.you_can - without end}
http://blog.rubybestpractices.com/

29

I would be concerned about long-time contributors that have a deep
impact on the project.

Not contributors that provide a couple of patches now and then.

···

On Fri, May 2, 2014 at 9:10 PM, Brandon Weaver <keystonelemur@gmail.com> wrote:

I'm equally concerned with both. Never underestimate the impact that the
attitude of contributors can have on a project.

--
Felipe Contreras

30

>And why are you ignoring my other arguments?
>
>1) DateTime.strftime with "%s %z" is *already* using the tz instead of UTC
>2) Time.strptime with "%s %z" is *already* using the tz (and Time.strftime)
>
>Why would you create this inconsistency? Even if you ignore the
>behavior of glibc, Ruby MRI is *already* using the timezone correctly
>for "%s %z" in several places. I would really like an answer to that.
>
> DateTime.parse("1970-01-01 01:00 +0100").strftime("%s %z")
> => "0 +0100"

According to the discussion in Japanese, formatting (output) is OK,
but parsing is not. For example, "Sat May 3 00:00:00 2014" can be
parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
because it contains contradicting information. Hence at least some
part of the original string should be ignored. That wouldn't happen
in output. According to Tadayoshi's opinion, time_t (%s)
fundamentally comes without timezone information from its definition,
so that the combination is meaningless, thus ignored.

Come on, time_t is irrelevant, we are talking about Ruby, and DateTime
does have an offset field, it doesn't rely solely on a large integer
like time_t. We don't have the limitations the C standard has.

I know unlike day of the week, timezone information does not
contradict with time_t. They are independent. I don't think his
opinion is universal truth, but at least I respect his opinion.
When our opinions differ, I try to persuade.

Exactly.

So please tell me, why do you want to parse date strings in form of
"%s %z"? Just for consistency? Or something git related? If git
somehow uses this kind of strings pretty often, that fact might be a
good reason to support. Otherwise you can always use _strptime()
method, which parses and retrieves as much information it finds, as
Tadayoshi stated before.

I already explained that Git uses this format to store dates, so it's
used on *every* *single* *commit* (twice). I thought that was already
evident, but apparently I must make it clearer.

Here, I wrote a simple parser[1] to exemplify this. It takes the raw
commit information stores it in a Ruby object, and then I try to print
this object back.

So would expect this:

  % git cat-file -p HEAD > expected
  % ruby git-parser HEAD > actual
  % diff -u expected actual

To show no diff, but instead I get this:

  --- expected 2014-05-03 14:04:13.300651626 -0500
  +++ actual 2014-05-03 14:03:59.076651245 -0500
  @@ -1,8 +1,8 @@
   tree 90046017e7ce9711ab0c732f46a24b7968c351c2
   parent b2feb643097a1ec0cbe79fc161f604b6265c049b
   parent 94f94fcbf2b1009da358fbe06edffbd206d9fa7a
  -author Junio C Hamano <gitster@pobox.com> 1398880902 -0700
  -committer Junio C Hamano <gitster@pobox.com> 1398880902 -0700
  +author Junio C Hamano <gitster@pobox.com> 1398880902 +0000
  +committer Junio C Hamano <gitster@pobox.com> 1398880902 +0000

   Merge git://github.com/git-l10n/git-po

Clearly, Ruby MRI's DateTime is unable to parse Git commits.

>Why are we talking about persuading him? If we, the project, agree
>that this is the way to go, why would the opinion of a single person
>hold hostage the change we all agree is right?

Because whole date/datetime is his masterpiece. He designed and
implemented it from scratch. He has been maintained it for long time.
I don't want to force him in any way just because his work is bundled
with Ruby. Just like I don't want to be forced to do anything just
because of Ruby is a part of something, e.g. a Linux distribution.

That is a bad analogy. Ruby is part of many distributions. His code is
not part of many projects.

In fact, this is not how people think in open source projects. It's
not his code, it's the projects' code. In fact, not even that, the
project belongs to the public domain.

Once I asked him for permission to bundle his work with Ruby, but I
didn't take it away from him. I don't want to lose him, nor date
subsystem, his long time effort and huge contribution to the Ruby
world, just because our opinion is different in corner cases.

If you lose him because of a disagreement on how "%s %z" should be
parsed (and he disagrees with everyone on this), maybe he wasn't worth
working with in the first place.

Cheers.

[1] http://pastie.org/9137204

···

On Sat, May 3, 2014 at 9:27 AM, Yukihiro Matsumoto <matz@ruby.or.jp> wrote:

In message "Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?" > on Sat, 3 May 2014 01:32:09 -0500, Felipe Contreras <felipe.contreras@gmail.com> writes:

--
Felipe Contreras

31

Matz, thanks for taking the time to deal with this.

It is much appreciated by at least some of us. :slight_smile:

According to the discussion in Japanese, formatting (output) is OK,
but parsing is not. For example, "Sat May 3 00:00:00 2014" can be
parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
because it contains contradicting information. Hence at least some
part of the original string should be ignored. That wouldn't happen
in output. According to Tadayoshi's opinion, time_t (%s)
fundamentally comes without timezone information from its definition,
so that the combination is meaningless, thus ignored.

DateTime.strptime defers to the man-page for strptime for almost it's entire definition:

10004 % ri DateTime.strptime | tail -3 | head -1
See also strptime(3) and strftime.

(from a previous email):

Remember, in the C specification, struct tm does not have a member to
preserve timezone (although glibc has). Your expectation to Time and
DateTime can only meet on some but not all platforms.

And the man-page explicitly states that resulting values are relative to the local time zone:

10009 % man 3 strptime | grep -C2 relative | head -5
     The strptime() function parses the string in the buffer buf, according to
     the string pointed to by format, and fills in the elements of the struc-
     ture pointed to by tm. The resulting values will be relative to the
     local time zone. Thus, it can be considered the reverse operation of
     strftime(3).

This implies that DateTime.strptime isn't living up to it's contract, yes?

···

On May 3, 2014, at 7:27, Yukihiro Matsumoto <matz@ruby.or.jp> wrote:

32

If you lose him because of a disagreement on how "%s %z" should be
parsed (and he disagrees with everyone on this), maybe he wasn't worth
working with in the first place.

In most open source projects, maintainers of a module/library/component of
the core library are the final arbiter of what patches are accepted into
their domain. Patches may be rejected for any reason or no reason.

That is simply not true.

Speaking as the maintainer of a significant upstream component of Ruby (Tk's
Mac bindings), I am grateful for patches. The submitter may very well be
smarter than me about the subject in question and I am happy to commit their
patch if the use-case is reasonably well-explained, and causes no
side-effects when applied.

However, sometimes I do not accept patches. This could be because I don't
understand the use case for the patch, do not agree with the solution to the
problem, or do not agree that the issue in question *is* a problem. In such
cases, the only time I would expect to be second-guessed by another member
of the project would be if their technical expertise were greater than or
equal to mine.

In most projects when one or more maintainers of other modules might
disagree, and then there's always a leader (e.g. Linus Torvalds) that
makes the final decision. So no, in most projects the module
maintainers are not the final arbiters of what goes in those modules.

In most cases, the "consensus" you are looking for simply does not exist.

But in this case there is. That's why Time.strptime() got fixed,
Rubinius's Time.strptime() got fixed, and Rubinius DateTime.strptime()
got fixed.

Patches are not reviewed by a committee, patches are typically reviewed by
individuals who provide expertise that other members of the project lack. If
an individual with unique or significant expertise leaves a project, there
simply may not be anyone to replace him or her. When the maintainer involved
is the original author of the code, this is especially true. Matz has
indicated as much with the maintainer in question.

There is a concept know as the "bus factor" that measures how
concentrated is the knowledge shared in the team. If losing a single
developer can cause such big problems, that's not ideal.

I can also echo others in this thread that the arrogance you have displayed
in your comments far overshadows any technical merit your arguments might
have. In my own domain, I welcome constructive disagreement and can even be
persuaded by it, but if you come at me with the kind of combative attitude
you have displayed, I will end the discussion quickly and advise you to
maintain your own fork of the code with your patch applied--that is, after
all, one of the benefits of open source.

So you don't care what is better for the Ruby project, you just want
to have nice and pleasant discussions. Got it.

[1] Bus factor - Wikipedia

···

On Sat, May 3, 2014 at 3:05 PM, Kevin Walzer <kw@codebykevin.com> wrote:

On 5/3/14, 3:24 PM, Felipe Contreras wrote:

--
Felipe Contreras

33

The two are not mutually exclusive. There's no reason why people cannot be
civil AND improve the community. Pretending it's a non-issue is only doing
yourself a disservice. If anything I feel you should apologize for your
rudeness to the core committers, it's completely unwarranted.

···

On Sat, May 3, 2014 at 3:33 PM, Felipe Contreras <felipe.contreras@gmail.com > wrote:

On Sat, May 3, 2014 at 3:05 PM, Kevin Walzer <kw@codebykevin.com> wrote:
> On 5/3/14, 3:24 PM, Felipe Contreras wrote:
>>
>> If you lose him because of a disagreement on how "%s %z" should be
>> parsed (and he disagrees with everyone on this), maybe he wasn't worth
>> working with in the first place.
>
> In most open source projects, maintainers of a module/library/component
of
> the core library are the final arbiter of what patches are accepted into
> their domain. Patches may be rejected for any reason or no reason.

That is simply not true.

> Speaking as the maintainer of a significant upstream component of Ruby
(Tk's
> Mac bindings), I am grateful for patches. The submitter may very well be
> smarter than me about the subject in question and I am happy to commit
their
> patch if the use-case is reasonably well-explained, and causes no
> side-effects when applied.
>
> However, sometimes I do not accept patches. This could be because I don't
> understand the use case for the patch, do not agree with the solution to
the
> problem, or do not agree that the issue in question *is* a problem. In
such
> cases, the only time I would expect to be second-guessed by another
member
> of the project would be if their technical expertise were greater than or
> equal to mine.

In most projects when one or more maintainers of other modules might
disagree, and then there's always a leader (e.g. Linus Torvalds) that
makes the final decision. So no, in most projects the module
maintainers are not the final arbiters of what goes in those modules.

> In most cases, the "consensus" you are looking for simply does not exist.

But in this case there is. That's why Time.strptime() got fixed,
Rubinius's Time.strptime() got fixed, and Rubinius DateTime.strptime()
got fixed.

> Patches are not reviewed by a committee, patches are typically reviewed
by
> individuals who provide expertise that other members of the project
lack. If
> an individual with unique or significant expertise leaves a project,
there
> simply may not be anyone to replace him or her. When the maintainer
involved
> is the original author of the code, this is especially true. Matz has
> indicated as much with the maintainer in question.

There is a concept know as the "bus factor" that measures how
concentrated is the knowledge shared in the team. If losing a single
developer can cause such big problems, that's not ideal.

> I can also echo others in this thread that the arrogance you have
displayed
> in your comments far overshadows any technical merit your arguments might
> have. In my own domain, I welcome constructive disagreement and can even
be
> persuaded by it, but if you come at me with the kind of combative
attitude
> you have displayed, I will end the discussion quickly and advise you to
> maintain your own fork of the code with your patch applied--that is,
after
> all, one of the benefits of open source.

So you don't care what is better for the Ruby project, you just want
to have nice and pleasant discussions. Got it.

[1] Bus factor - Wikipedia

--
Felipe Contreras

34

In most open source projects, maintainers of a module/library/component of the core library are the final arbiter of what patches are accepted into their domain. Patches may be rejected for any reason or no reason.

Speaking as the maintainer of a significant upstream component of Ruby (Tk's Mac bindings), I am grateful for patches. The submitter may very well be smarter than me about the subject in question and I am happy to commit their patch if the use-case is reasonably well-explained, and causes no side-effects when applied.

However, sometimes I do not accept patches. This could be because I don't understand the use case for the patch, do not agree with the solution to the problem, or do not agree that the issue in question *is* a problem. In such cases, the only time I would expect to be second-guessed by another member of the project would be if their technical expertise were greater than or equal to mine.

In most cases, the "consensus" you are looking for simply does not exist. Patches are not reviewed by a committee, patches are typically reviewed by individuals who provide expertise that other members of the project lack. If an individual with unique or significant expertise leaves a project, there simply may not be anyone to replace him or her. When the maintainer involved is the original author of the code, this is especially true. Matz has indicated as much with the maintainer in question.

I can also echo others in this thread that the arrogance you have displayed in your comments far overshadows any technical merit your arguments might have. In my own domain, I welcome constructive disagreement and can even be persuaded by it, but if you come at me with the kind of combative attitude you have displayed, I will end the discussion quickly and advise you to maintain your own fork of the code with your patch applied--that is, after all, one of the benefits of open source.

--Kevin

···

On 5/3/14, 3:24 PM, Felipe Contreras wrote:

If you lose him because of a disagreement on how "%s %z" should be
parsed (and he disagrees with everyone on this), maybe he wasn't worth
working with in the first place.

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

35

The two are not mutually exclusive.

And who argued they were?

Besides it's a red herring, Kevin was talking about a hypothetical
situation where a person with combative attitude tried to persuade
him.

In that situation he specifically said he didn't care if such person
was right, therefore he didn't care if the proposed change would
improve the project.

Pretending it's a non-issue is only doing
yourself a disservice. If anything I feel you should apologize for your
rudeness to the core committers, it's completely unwarranted.

I won't.

If you don't want to fix Ruby's broken DateTime.strptime's handling of
"%s %z" because some guy didn't apologize, that says to me that your
priorities are wrong, and that improving Ruby is definitely not as
high as it should be.

···

On Sat, May 3, 2014 at 3:51 PM, Brandon Weaver <keystonelemur@gmail.com> wrote:

--
Felipe Contreras

36

Matz has backed him despite your protests.

He has not backed him. If you din't read correctly he accepts the
timezone representation is independent of the date, that means he has
no problem in parsing it the way I propose.

He said he respected Tadayoshi's opinion, that doesn't mean he shares it.

And, in my experience, civility is a better tool to achieving those
ends than flame wars.

Linux is a project well know for what some call "hostile environment",
however, it's the most successful software project in history by far.
And it's because of their no-bullshit attitude.

If we were in the LKML mailing list we would be discussing about the
patch and it's technical merits, and not this ad hominem bullshit.

You can listen from Linus' boss why "you don't always need to be
nice"[1]. There are even papers about it[2].

But I'm done talking about irrelevant stuff. Unless you have something
to say about the DateTime.strptime() bug, I'm not interested.

[1] https://www.youtube.com/watch?v=7XTHdcmjenI
[2] http://www.ilr.cornell.edu/directory/ja26531/downloads/Liberating_role_of_conflict_in_group_creativity.pdf

···

On Sat, May 3, 2014 at 4:32 PM, Kevin Walzer <kw@codebykevin.com> wrote:

--
Felipe Contreras

37

In most open source projects, maintainers of a module/library/component of
the core library are the final arbiter of what patches are accepted into
their domain. Patches may be rejected for any reason or no reason.

That is simply not true.

It's certainly true of all the projects I've been associated with: Tcl/Tk, Emacs on the Mac, my own individual OSS projects. There is no central set of rules that compel acceptance of a patch--it's always left to the judgment of the individual maintainer.

In most projects when one or more maintainers of other modules might
disagree, and then there's always a leader (e.g. Linus Torvalds) that
makes the final decision. So no, in most projects the module
maintainers are not the final arbiters of what goes in those modules.

This depends on the project. Tcl/Tk, the project I work the most with, lacks such a BDFL figure. John Osterhout, the inventor of Tcl, turned maintenance of the language over to a core group that does not have a single leader. While this group votes on significant new features or additions to the language, it does not sign off on patches and bugfixes.

In most cases, the "consensus" you are looking for simply does not exist.

But in this case there is. That's why Time.strptime() got fixed,
Rubinius's Time.strptime() got fixed, and Rubinius DateTime.strptime()
got fixed.

Maybe that's so, and maybe there is no technical reason for the patch you've submitted to be rejected. But the maintainer has rejected it, and (getting back to your earlier point) Matz has backed him despite your protests. Based on your own stated criteria, it seems to me that this means the subject is closed--unless you are implying Matz is wrong as well.

There is a concept know as the "bus factor" that measures how
concentrated is the knowledge shared in the team. If losing a single
developer can cause such big problems, that's not ideal.

No, it's not, but sometimes it's what a project has to work with. I have less expertise than my predecessor as Mac maintainer of Tk (he works at Apple now), but no one else stepped forward to replace him. It was me or nobody. That's life in the open-source world.

So you don't care what is better for the Ruby project, you just want
to have nice and pleasant discussions. Got it.

I do care about the open-source projects I work with, and I do want them to thrive. And, in my experience, civility is a better tool to achieving those ends than flame wars. Really, do you have any appreciation of how you are coming across? Suggesting that someone's nationality is to blame for their rejecting your patch? Suggesting that the project would be better off without them when the project leader has said they are practically indispensable?

Though you're apparently scornful of civility, "nice and pleasant discussions" can be a useful indicator of the health of an open-source project. Tcl lags behind Ruby in its mindshare and the size of its developer community, but it persists, in no small part because the people associated with the community get along well, and are friendly and helpful to newcomers--in addition to being brilliant and dedicated engineers.

You might want to consider that you catch more flies with honey than you do vinegar.

--Kevin

···

On 5/3/14, 4:33 PM, Felipe Contreras wrote:

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

38

.

Civility is an important value in many software communities because it
facilitates better work.

That is an *assumption* you hold, and it's not backed up by the
evidence I just presented.

But I'm done talking about irrelevant stuff. Unless you have something
to say about the DateTime.strptime() bug, I'm not interested.

I have no opinion on the technical merits of your patch.

Then I see no reason to discuss with you.

I see you have set up a fork of git because your patches were not being
accepted.

The vast majority of my patches are accepted[1].

[1] https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo

···

On Sat, May 3, 2014 at 5:36 PM, Kevin Walzer <kw@codebykevin.com> wrote:

--
Felipe Contreras

39

Linux is a project well know for what some call "hostile environment",
however, it's the most successful software project in history by far.
And it's because of their no-bullshit attitude.

Yes, this is true. Linux is very reflective of the personality of its leader. However, does this mean that every project functions this way, or must?

If we were in the LKML mailing list we would be discussing about the
patch and it's technical merits, and not this ad hominem bullshit.

Yes, but this isn't the LKML mailing list, is it?

You can listen from Linus' boss why "you don't always need to be
nice"[1]. There are even papers about it[2].

If this were the Python, Tcl, Cocoa-dev, MacPorts, or Fink mailing lists, consideration of your tone would be very much a subject of discussion. Civility is an important value in many software communities because it facilitates better work. Coming in with guns blazing, demanding recognition of your technical brilliance and castigating anyone who disagrees with you as an idiot is not constructive in many communities, including here.

But I'm done talking about irrelevant stuff. Unless you have something
to say about the DateTime.strptime() bug, I'm not interested.

I have no opinion on the technical merits of your patch. My purpose, as a software maintainer, was to shed a bit of light on why your patch may have been rejected. That is, after, the subject of this thread.

I see you have set up a fork of git because your patches were not being accepted. You might have less frustration if you were to do the same with Ruby.

--Kevin

···

On 5/3/14, 6:16 PM, Felipe Contreras wrote:

On Sat, May 3, 2014 at 4:32 PM, Kevin Walzer <kw@codebykevin.com> wrote:

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

40

Actually, just to make it clear, originally you said "%s" implies UTC,
but as I showed above DateTime.strtime() doesn't actually do that,
that was the point I wanted you to answer.

So do you agree now that "%s" does *not* imply UTC?

···

On Sat, May 3, 2014 at 9:27 AM, Yukihiro Matsumoto <matz@ruby.or.jp> wrote:

In message "Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?" > on Sat, 3 May 2014 01:32:09 -0500, Felipe Contreras <felipe.contreras@gmail.com> writes:

>And why are you ignoring my other arguments?
>
>1) DateTime.strftime with "%s %z" is *already* using the tz instead of UTC
>2) Time.strptime with "%s %z" is *already* using the tz (and Time.strftime)
>
>Why would you create this inconsistency? Even if you ignore the
>behavior of glibc, Ruby MRI is *already* using the timezone correctly
>for "%s %z" in several places. I would really like an answer to that.
>
> DateTime.parse("1970-01-01 01:00 +0100").strftime("%s %z")
> => "0 +0100"

According to the discussion in Japanese, formatting (output) is OK,
but parsing is not. For example, "Sat May 3 00:00:00 2014" can be
parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
because it contains contradicting information. Hence at least some
part of the original string should be ignored. That wouldn't happen
in output. According to Tadayoshi's opinion, time_t (%s)
fundamentally comes without timezone information from its definition,
so that the combination is meaningless, thus ignored.

--
Felipe Contreras