Hi Nicholas,

Thanks for the feedback and seems this feedback is just based on *only last
interaction* for HDDS-14040 which induced the issue and where we tried to
fix the actual issue.

*The interaction was not good due to fact in difference in expection
between us for discussion (since the problem is complicated),*
- I prefer POC code for experiments and getting quick test result, but
you prefer exact implementation and test result. But I feel we get same
output, and its based on different working style to achieve same result.
- You expect more details written on temporary doc and full flow to take
decision, but as I know the flow related to that area, I tend to skip for
discussion as seems un-necessary. Some deep unrelated behavior, as not in
finger tip, needs relook code.

*Coming to fact of process being followed for the bug:*
HDDS-14040:
- This was reviewed and approved by you as expert review for ratis & ozone
integration and merged only after that.
- Test cases are added with due-deligence, covering scenarios and covering
scenario impact as thought during that time.

Fix: all test cases are added and merged only after approval.

*Improvement for Ratis integration with ozone for DN flow:*
- Already lot of discussion has happened to handle flaky nature of ratis
and ozone integration. Still no concrete solution.


*Coming to the concerns you have mentioned:*


*- Why did the change get merged?  No tests added along with the changes.*
I have never merged any PR without the approval and being reviewed. If any
facts, please share.
Showing *urgency* to fix problem is justifiable (still taken 2 monts to get
fixed) and expected for delivery.

- When we were discussing the issue, I found he actually neither understood
the code nor the problem,
- Sumit initially proposed some other changes without trying to
completely understand
the code first.
*This is a communication gap* of your expectation and my delivery as *doc*.
I may know the flow as required for the bug, but you have asked for
complete flow in doc as you might be trying to understand and to take
decision for solution. This does not provide any outcome of my
understanding.

- When we came up with a potential bug fix, Sumit wanted to merge it
without adding new tests.
- When Sumit agreed to add tests, the tests he proposed again were way too
simple.
IMO, have added all required test cases and scenario as suggested. Adding
test cases are never being objected and neither in comments being ignored.
I do appreciate your opinion about getting tested on multiple internal
environment.

Still if any sceanrio is missed for test case in apache ozone, and need
some improvement, eager to fix and handle. Please share if anything
remaining as not handled.

So I think all comments are based on different expectation that happened
during discussion, but *Apache* *Ozone process is never compromised and
eager to take expert opinion as I lack Ratis depth code flow*. And always
there is an improvement.

@Nicholas: Apache Ozone contribution can never be denied based on internal
discussion and differences in opinion about the proceeding. Please recheck
your opinion over this.


Regards
Sumit

On Thu, Aug 6, 2026 at 1:49 PM Tsz Wo Sze <[email protected]> wrote:

> Hi Sammi and others,
>
> Thanks for bringing up this discussion!
>
> I worked with him closely in the same company previously.  One of the
> issues caused job slowness, which was reported by some users.  Sumit tried
> to fix it.  He committed some code changes.  Unfortunately, that particular
> change could cause data loss, a much more severe problem.  The good thing
> was that, although the change was merged, the problem had been discovered
> before causing real data loss.
>
> Of course, all developers including you and me are susceptible to
> introducing bugs.  However, the manner in which the bug was introduced,
> along with Sumit’s subsequent handling of the issue, has given rise to
> significant concern.
>
> - Why did the change get merged?  No tests added along with the changes.
> Sumit did test it manually but the manual tests conducted were way too
> simple.
>
> - When we were discussing the issue, I found he actually
> neither understood the code nor the problem, but he dared to merge
> the code.  Note that the code he changed was at the most important data
> path in Ozone.
>
> - Sumit initially proposed some other changes without trying to completely
> understand the code first.
>
> - When we came up with a potential bug fix, Sumit wanted to merge it
> without adding new tests.  The reason was that adding new tests was not
> easy.  It was understandable but unacceptable.
>
> - When Sumit agreed to add tests, the tests he proposed again were way too
> simple.
>
> We spent a long time having many discussions.  He finally was convinced --
> for that particular issue, we had to understand the problem first and also
> had to test the change seriously.
>
> I would agree that Sumit is smart and very good at debugging, and he has
> made a lot of contributions to Ozone.  However, he might be immature to
> handle important issues.  Therefore, I would disagree with nominating him
> as a PMC member.
>
> Regards,
> Tsz-Wo
>
>
>
>
> On Thu, Jul 30, 2026 at 12:14 AM Sammi Chen <[email protected]> wrote:
>
> > Dear PMCs,
> >
> > I would like to propose adding Sumit Agrawal[1] to the PMC.
> >
> >  Sumit
> > - has been a committer on 2023-05-22, 3 years ago [2]
> > - has contributed 156 PRs [3], 476 reviews [4]
> >
> > These are the highlights of his contributions
> > - Fix broken Quota function with FSO bucket and Legacy bucket, and later
> > quota for snapshot support. [5][6]
> > - Improve HDDS block deletion efficiency. [7]
> > - Handling disk issues, preventing disk becomes full, and handle
> duplicate
> > container replicas on a datanode[8]
> > - Distributed tracing improvement, migrate from OpenTracing to
> > OpenTelemetry[9]
> > - Migrating Ozone Manager replication from post Ratis execution to Pre
> > Ratis execution, design discussion, and work on the POC. [10][11]
> >
> > Besides above feature based contributions, Sumit also has a lot of
> > production cluster issue investigation and fix experiences, and
> contributed
> > a lot of critical fixes to Ozone,
> > including performance bottleneck resolve, data loss prevention, etc.
> > I think he is a good candidate for Ozone PMC. He will bring his unique
> > insight to the community. What do you think?
> >
> > Disclaimer: We share the same employer.
> >
> > - Sammi Chen
> >
> > [1] https://github.com/sumitagrawl
> > [2] https://whimsy.apache.org/roster/committer/sumitagrawal
> > [3]
> > https://github.com/apache/ozone/issues?q=is%3Apr%20author%3Asumitagrawl
> > [4]
> >
> https://github.com/apache/ozone/pulls?q=is%3Apr+reviewed-by%3Asumitagrawl+
> > [5] https://issues.apache.org/jira/browse/HDDS-7479
> > [6] https://issues.apache.org/jira/browse/HDDS-7598
> > [7] https://issues.apache.org/jira/browse/HDDS-6548
> > [8] https://issues.apache.org/jira/browse/HDDS-12564
> > [9] https://issues.apache.org/jira/browse/HDDS-13679
> > [10] https://issues.apache.org/jira/browse/HDDS-11897
> > [11] https://issues.apache.org/jira/browse/HDDS-11900
> >
>


-- 
*Sumit Agrawal* | Senior Staff Engineer
cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
------------------------------

Reply via email to