Hi, I noticed my PR was marked as “denounced” after the /recheck. Could you please guide me on what needs to be fixed or improved so I can resolve it? #2367
Atofinite5
started this conversation in
General
Replies: 4 comments 3 replies
|
Hi, I rechecked the PR as suggested, but it’s currently marked as “denounced.” Could you please clarify what the exact issue is so I can address it properly? I focused on fixing the critical bug first since it was impacting functionality. Once I have your clarification and resolve this, I’ll raise a separate PR for a smaller, clearly scoped issue—likely #2217, as it seems like the cleanest candidate. Thanks! |
1 reply
|
Dear Bas Zalmstra,
I sincerely apologize for my behavior and for wasting your time. I
understand why my actions were seen as rude and unprofessional, and I take
full responsibility for failing to follow the project's AI policy and
templates.
Please do not denounce me. I would appreciate it if you could simply close
or delete the pull requests instead. I assure you that this will not happen
again, and I will be more mindful of the contribution guidelines in the
future.
Thank you for your patience, and I hope you can pardon this mistake.
Best regards,
Bhargav Kalambhe
…On Tue, 21 Apr, 2026, 12:21 pm Bas Zalmstra, ***@***.***> wrote:
I consider your behavior spam. Your PRs are clearly completely
AI-generated. It doesn't look like a single human thought went into them.
None of your PRs solves real problems. And you didn't even take the time to
fill out the PR templates. This is just wasting my time as a maintainer,
and honestly, I find that pretty rude.
That's the reason I denounced you. If you feel like in the future you want
to contribute as a human, feel free to ping me.
See: Our AI_POLICY
<https://github.com/conda/rattler/blob/main/AI_POLICY.md>
—
Reply to this email directly, view it on GitHub
<#2367?email_source=notifications&email_token=BKIAVXULPRC35DOHBXX276T4W4LAJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGQ4TEMBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16649204>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BKIAVXTDYP4DSIS6BHVVLXT4W4LAJAVCNFSM6AAAAACYANGOFSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRUHEZDANA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
1 reply
|
Dear Bas Zalmstra,
I sincerely apologize again for my previous actions. I understand that I
have lost your trust, but I assure you that I will never repeat this
mistake. I am committed to following the community guidelines and the AI
policy moving forward.
Please consider removing the denounce status. I truly regret my behavior
and hope for a second chance to engage with the community correctly.
Thank you for your time and understanding.
Best regards,
Bhargav Kalambhe
…On Tue, 21 Apr, 2026, 12:33 pm Bas Zalmstra, ***@***.***> wrote:
I have no reason to trust you at this point. You can still make issues if
you want. Just engage with the community first.
—
Reply to this email directly, view it on GitHub
<#2367?email_source=notifications&email_token=BKIAVXVVRIHAFWXIPR7XU7D4W4MNZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGQ4TGMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16649323>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BKIAVXVZ6MLRT4DAQW6AL534W4MNZAVCNFSM6AAAAACYANGOFSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRUHEZTEMY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
1 reply
|
Dear Bas Zalmstra,
I understand and respect your position. Thank you for the clarification
regarding future issues and pull requests. I will be sure to keep your
advice in mind and ensure that any future contributions are meaningful and
follow the project's guidelines.
Best regards,
Bhargav Kalambhe
…On Tue, 21 Apr, 2026, 12:49 pm Bas Zalmstra, ***@***.***> wrote:
You can still engage through issues. You can still create PRs; they will
just be closed immediately. If you feel like you made a good PR, ping me
there. But be warned that if it's still AI slop, I will block you outright.
—
Reply to this email directly, view it on GitHub
<#2367?email_source=notifications&email_token=BKIAVXQ5GVAKHPIDCSCNNC34W4OJBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGQ4TINRUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16649464>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BKIAVXTG3BGHFV7IV3Q32634W4OJBAVCNFSM6AAAAACYANGOFSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRUHE2DMNA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Unix-style), it already handled the case "cygpath not installed" gracefully — falling back to a plain POSIX path. But for
any other cygpath error (disk I/O glitch, weird encoding in the output, process failure, etc.), the code literally said
panic!("{e}") and crashed the whole program.
Why fix it: Libraries shouldn't crash the programs calling them. One branch of the same match already did the right thing;
the other didn't. Inconsistent.
What changed: Replaced the panic! with the same fallback the "not found" branch uses, plus a tracing::warn! so the error
shows up in logs instead of vanishing silently. 17 lines total.
memmap2::Mmap::map is unsafe because mapping a file that gets modified underneath you causes a segfault (SIGBUS). Rust
convention says every unsafe block needs a // SAFETY: comment explaining why it's actually safe. This one had none.
Why fix it: When someone later changes file-handling code — Windows sharing flags, how the gateway writes new repodata,
whether the file object is kept alive — they need to know the mmap's safety depends on those. Without the comment, it's
invisible tribal knowledge.
What changed: Added a 24-line // SAFETY: comment listing the four concrete invariants that hold (file opened read-only,
kept alive for mmap's lifetime, Windows FILE_SHARE_DELETE flag set, gateway uses atomic write-then-rename). Zero code
change — pure documentation.
program with panic!:
is unsupported but shouldn't crash
panic
Why fix it: The solver is a library. If a caller passes malformed input, the library should return an error, not abort the
whole process. Panics there meant a tool like pixi or rattler-build would just die instead of reporting a useful error to
the user.
Function signature now returns Result<ConditionId, ParseMatchSpecError> instead of a bare ConditionId.
The .unwrap() became ?.
The reachable panic became Err(ParseMatchSpecError::InvalidCondition(...)), using an existing error variant (no new
public API).
The unreachable panic became unreachable!() with a comment explaining why it can't be hit.
Callers updated: one inline with ?, and one inside a .flat_map(...) closure — which couldn't use ? directly, so the
condition-parsing got pulled out into a pre-pass that collects Vec<(MatchSpec, Option)> with
collect::<Result<_, _>>()?.
Errors flow through SolveError: #[from] ParseMatchSpecError, which already existed.
All reactions