public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Amit Choudhary <amitchoudhary0523@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Your toxic comments.
Date: Sun, 13 Jun 2021 17:26:21 +0530	[thread overview]
Message-ID: <CAFf+5ziNY=1im4pDdxSaXsHL6Xic5xXsFomikgr6Nb1ePvetHQ@mail.gmail.com> (raw)
In-Reply-To: <419466EF-C886-472A-9A50-7DC1239BA17E@linaro.org>

On Sun, Jun 13, 2021 at 4:46 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> > Il giorno 13 giu 2021, alle ore 08:05, Amit Choudhary <amitchoudhary0523@gmail.com> ha scritto:
> >
> > Who cares about contributing to glibc?
>
> You, since you continue to reply our messages.


If someone says something wrong about me or my algorithm then I am
going to respond. I have said many times that I don't care about my
code getting included in glibc or not.

>
> >
> > It looks like that you people think that contributing to glibc is a great deal.
> >
> > It is not a great deal at all.
>
> So stop interacting with us the, why do you need to have the last word?

Again, if someone says something wrong about me or my algorithm then I
am going to respond.

> >
> > My patches are in linux kernel since 2005-2006 and those guys are
> > wonderful to work with. Very supportive and encouraging. Also, they
> > just ask people to send the patch, they do all the testing /
> > verification themselves unlike here in glibc where you ask
> > contributors to fix other parts of the system also.
> >
> > The supreme open source project is linux kernel and my patches are in there.
> >
> > How many people from glibc have their patches in linux kernel?
> >
> > Does Siddhesh and you (adhemerval.zanella@linaro.org) have any patch
> > in linux kernel?
> >
> > Contributing to linux kernel is much much much bigger deal than
> > contributing in glibc.
>
> Ok, take care. If you want to contribute, please tone down these personal attacks since the toxic behavior came exclusively from you.
>
> Otherwise I will personally block any contribution you send.
>

Siddhesh started all this by making stupid comments. I will write here
what he wrote:


""""Case 1"""": 4. Given that the benchmark program is outside of the
benchtests infrastructure (because this is clearly not the benchtests
program), there is no information about how the benchmark is run and
what conditions affect its output..

Answer: So, he did not ask me what I was doing but made a completely
stupid statement. Anyways, how else I would run benchmark other than
the way it is explained in glibc.

Also, he did not ask me whether I had included my algorithm in
benchmarks tests or not, but he just went ahead and made a stupid
statement. I had included my algorithm in bench-strstr.c and then ran
the tests as instructed in glibc.

""""Case 2"""": 3. ... The benchmark results shared don't actually
indicate which length pairs result in those worst case performances
but if I had to assume that it's related to glibc benchmark inputs,
(there's one input less than the glibc benchmarks) it appears that the
performance starts going downhill from 224 byte haystacks, especially
with misaligned strings.

Answer: Again, he did not ask me what I was doing and made a stupid
statement. I modified bench-strstr.out so that the results are easily
readable by people. Siddhesh could have asked for original
bench-strstr.out and I would have provided that.

""""Case 3"""": 5. The baseline for comparison is not clear. Is it the
default strstr() in string/strstr.c?  Is it the system strstr()?  In
the latter case, it could be anything from string/strstr.c to the
various microarchitecture-specific asm ifuncs.

Answer: It looks like he himself hasn't seen what is there in
bench-strstr.c and bench tests in glibc. If he had seen that then he
would have made this statement. So, he makes statements without
knowing much.

""""Case 5"""": 7. Refusal to use the glibc-benchtests - either in its
current form or by adding more inputs that the community agrees as
relevant - is IMO a blocker to getting any changes accepted to
strstr().  A better strstr() must show better results on the
benchmarks, without which future maintenance of the function will be
challenging.

Answer: Again, he said something without looking at my latest mail. My
latest mail had cleary written that I ran benchmark tests.

""""Case 6"""": 1. First and foremost, Amit has been insinuating
racial discrimination or crying victim when someone makes suggestions
for verification or points out flaws in the algorithm.  He was warned
once[1] but has refused to treat community members with respect.  Let
this not be the low we set for acceptable behaviour in the community.

Answer: I made this statement only once because I was skeptical and I
got the answer and after that I did not do anything of this sort. So,
Siddhesh wants me to respect the community but the community can treat
me any way it wants. If you want respect, then you should give respect
also.

""""Case 7"""": 2. There is a plain text algorithm and several C code
snippets, none of which have proper copyright notices.  There is no
indication even of whether Amit owns the copyright for the shared
content (as opposed to his employer since many employers claim
ownership for everything the employee creates) or whether he has given
us permission to use the content.

                        3. On a related point, it is unclear if Amit
or his employer have signed a copyright assignment with the FSF.  I
personally would like to see glibc move away from the assignment like
gcc did recently, but that's an orthogonal point at the moment.

Answer: What kind of comment is this? So, if anyone sends a patch to
glibc then he has to provide all these before sending a patch. If this
is a requirement then why was it not informed to me when I sent my
first mail. Why didn't Siddhesh made this comment on my first mail.?

""""Case 8"""": 4. Amit has on various occasions expressed disinterest
in contributing to glibc and put conditions on what he will or will
not do even before posting a single line patch.  I have no confidence
that if we do end up accepting his contribution at some point, he will
make himself available to maintain the code he contributed, leaving
the community to deal with the technical debt.

Answer: I expressed disinterest because at that time people were
behaving as if contributing to glibc is a very big deal and even if I
am not treated with respect by the community, I should put up with it.
Secondly, there was an outstanding point of whether average cases are
more important or worst cases. Many times, I myself said that my
algorithm is not good for worst cases. Why would I send a patch when I
know that it will not be accepted?

              If the requirement is that a person who contributes to
glibc should maintain his contribution for the entire life then it
should have been made clear in reply to my first mail itself.

""""Case 9"""": 6. Amit has made handwavy claims about why a certain
set of inputs matter over others without providing any references to
prior art or reviewable experimental data that can back his claims.
The proposal needs clearer commentary here with proper references.

Answer: Again it is not clear what claims I have made and whether I
have provided backing data or not? I made only two claims - my
algorithm is faster than strstr() for average case and slower in worst
cases. And I had sent the results in the mail. Siddhesh made all his
statements without looking at my mail. Shouldn't he have read all the
mails before replying?

==============

At this point, just before Siddhesh sent his meaningless mail,
everything was coming on track. I sent results, and Paul asked me to
improve my algorithm and things were taking shape. But then Siddhesh's
email derailed it all.

One last point: If you want respect, then please give respect also.

Amit

  reply	other threads:[~2021-06-13 11:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-13  8:58 Amit Choudhary
2021-06-13 10:51 ` Adhemerval Zanella
2021-06-13 11:05   ` Amit Choudhary
2021-06-13 11:16     ` Adhemerval Zanella
2021-06-13 11:56       ` Amit Choudhary [this message]
2021-06-13 13:46         ` Siddhesh Poyarekar
2021-06-13 13:58           ` Amit Choudhary
2021-06-13 14:07             ` Amit Choudhary
2021-06-13 14:19 ` Unacceptable behaviour by Amit Choudhary Dmitry V. Levin
2021-06-14 19:02   ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFf+5ziNY=1im4pDdxSaXsHL6Xic5xXsFomikgr6Nb1ePvetHQ@mail.gmail.com' \
    --to=amitchoudhary0523@gmail.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@gotplt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).