Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion with amjoseph #282862

Closed
zimbatm opened this issue Jan 22, 2024 · 5 comments
Closed

Discussion with amjoseph #282862

zimbatm opened this issue Jan 22, 2024 · 5 comments

Comments

@zimbatm
Copy link
Member

zimbatm commented Jan 22, 2024

          https://github.com/NixOS/nixpkgs/pull/275947 was a self-merge without any approvals.

Since it had no approvals, I self-merged the correction #282220 without waiting for approvals.

What exactly is the problem here?

Also, please explain in detail the deliberative process which led to this "shoot first, ask questions later" behavior on your part. If this repo is now zimbatimpkgs, or think you can treat us like your own personal employees, I will find better things to do with my time.

Please contact me over email/matrix/however you like so we can clear things up.

Yeah discussing it here works for me.

Originally posted by @amjoseph-nixpkgs in #50105 (comment)

@zimbatm
Copy link
Member Author

zimbatm commented Jan 22, 2024

Let's split things out so we don't pollute the other thread. I also marked the comments as off-topic, this is not a judgement on their content.

@zimbatm
Copy link
Member Author

zimbatm commented Jan 22, 2024

@amjoseph-nixpkgs this is not about me. I would rather not be involved in this TBH. But I see that people are leaving feedback, and you are ignoring them. This is not amjoseph's nixpkgs either. In order for this to work, you have to respond to some of the feedback so that over time, we find some sort of workable equilibrium that works for everybody.

Also, please explain in detail the deliberative process which led to this "shoot first, ask questions later" behavior on your part.

This is not the first time that I have seen this pattern, and I remember leaving you a note a while back already.

@SomeoneSerge
Copy link
Contributor

Hi, and thanks to all of the previous commenters.

You're right I have self-merged a PR touching a very sensitive part of Nixpkgs, and you're right I merged code of fairly inferior quality (the fact we could remove most of it in the next commits speaks to support that). That was a compromise and I knew it. When you posted the notice in the original PR I took it as you saying it was a bad compromise, which is a fair opinion. I'll own my mistakes if we establish I made a poor choice. To the best of my knowledge, no damage had been done to the builds, evaluation, or any automation at that point. I think we had the time to have a conversation about how to restructure (or write from scratch) things properly, without anyone ever having to stop consuming e.g. certain python packages in nixpkgs that I sought to unbreak. Your input in this conversation clearly would've been of great value. I'm sure your libcxx PR is. If you had waited with the "relocation" changes a few hours longer I (or someone else from @NixOS/cuda-maintainers) would've very likely spotted the eval errors that later leaked into Samuel's nixpkgs-upkeep and into the CI bumping the channels. I consider that rash and slightly damaging. The damage can be e.g. measured in CI hours, or in hours of people waiting for the channel. All three of the self-merged PRs (counting mine) may have also damaged our trust model, which is what we're now trying to compensate for.

commit access

Nixpkgs' security model and merge-bots aside, my personal opinion is that the commit access today should only be suspended when there's a reason to expect (more) destructive activity. To me the "relocation" PR seemed like a one off thing, so I don't think the suspension was called for

@zimbatm
Copy link
Member Author

zimbatm commented Jan 22, 2024

Self-merging is a symptom and not the issue at hand. The issue that I observe here is a breakdown in communication. Since nixpkgs is consensus-driven, communication is an essential mechanism that we require from committers. If somebody gives feedback, it should be taken into account. Maybe you disagree with the feedback, and that's fine, but there should be a conversation at least. And some sense that you are trying to seek consensus. This is not the first time that I see amjoseph not doing this.

If somebody ignores what other people are saying, it creates a situation where nixpkgs is "theirs". And other contributors get demoralized. I'm sorry, and maybe there is a better way to handle this, but if I see a situation like that, the only remaining option I see is to remove commit access.

My hope is that it forces the person to come to the table and have a conversation. I can also be wrong and miss some context. But I would like to get that sense.

@ghost ghost mentioned this issue Jan 23, 2024
@zimbatm
Copy link
Member Author

zimbatm commented Jan 25, 2024

amjoseph decided to delete their github account instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants