-
-
Notifications
You must be signed in to change notification settings - Fork 9
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
I am willing to be a maintainer |
recipe/meta.yaml
Outdated
- h-vetinari | ||
- oblute | ||
- dsangillo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's one thing to add yourself, but don't remove other maintainers.
Please double-check that the requirements are still up-to-date with upstream |
I appreciate that, though I have very little to go on here. Your github profile has no (publicly) visible content, and maintenance is often more involved than just updating the version & hash. Removing the other maintainers here (even if by accident) - which would remove their access once the feedstock is rerendered -, also doesn't give me a warm and fuzzy feeling about handing you the keys, so to speak. Basically, I'm gonna suggest that you keep raising a few PRs here (I just saw that upstream already released 0.20.0, though with another tag-format, so the bot doesn't pick it up), and once you understand the operations of the feedstock & various bots here better, I'd be very happy to have you join as a maintainer. |
|
You quoted my statement but didn't add any response yourself? I find you closing the PR without comment to be quite immature. There's no automatic right to maintainership - you need to show you can be trusted, and one single PR simply doesn't cut it, especially with these kinds of mistakes and style of communication. |
Hi h-vetinari, My apologies. I am new to conda-forge this week and am still learning. I removed you by mistake while the PR was still marked [WIP] and added you back. I believe @oblute is no longer maintaining this package but I will confirm with my team on Monday as well as bring up removing myself as a maintainer for the time being. At any rate, thank you for taking the time to review! Best, |
No problem. There's a lot of new things to learn, and you can start learning them as a contributor, without having to be a maintainer. Even if @oblute is (or were) on your team, please don't remove her. As a maintainer she can perfectly well remove herself, but at the very least she needs to confirm that she wants to be removed. |
@h-vetinari I appreciate the concern. But @dsangillo do work together, and I am no longer going to be maintaining a portion of the feedstocks I've contributed and he and my other teammates will continue. So, he had full right and permission to remove me, and will be doing it for others as well. I understand best practices, but I wish there had been a bit more respect among fellow contributors on this thread. Regardless, I'd like to stay removed, and am happy to have @dsangillo take over. I trust that it will be well maintained. Thanks. |
Glad to hear it!
I understand the difficulties of maintaining so many feedstock, as well as those of managing a team, and the difficulties of joining such a team as a newcomer. Still, I do not see where I have been disrespectful - all I had to go on was an account with no visible history, and a PR containing several rookie mistakes (that furthermore would lead to a kind of "hostile takeover" by removing the rights of the existing maintainers). Despite that I stayed welcoming ("once [...], I'd be very happy to have you join as a maintainer"), but I will defend the choice to not hand out maintainership "no questions asked" under such circumstances. I think it's amazing that you or your employer are paying people (apparently?) to maintain feedstocks, genuinely! Still there's a measure of trust that's required with the attendant risks & responsibilities of maintainership, and I'm not sure what the best way is for someone who starts from scratch (well, other than starting out by submitting PRs). I suggest you help smoothen the way for David on the other feedstocks a bit by vouching for him proactively (or at least, he can link back to your comment here). It would have also been easier here if he had been a maintainer of any other feedstock already, but this is the very first, it seems. In closing, it's not my intention to block your progress here, and I welcome David as a contributor. Please just be aware of the responsibilities (and potential for abuse!) that exists by granting maintainership rights to anyone, and please keep communication about what needs to be done for a given PR visible on Github (and not some internal system). In particular, I'd like newcomers like David to ask publicly in case of any doubt before merging stuff themselves because of some internal deadlines/KPIs or whatever. |
Given that there was no response on conda-forge/conda-forge.github.io#1507, I'm fine to move this forward. @conda-forge-admin, please rerender |
…a-forge-pinning 2021.09.06.19.10.42
I appreciate your response! I've never before had someone be so concerned about a new maintainer who hasn't maintained other feedstocks - have to start somewhere, right? It's not as if anyone here is suggesting someone become a member of the core team without any experience contributing. I saw the issue you created. It's been confusing to me...multiple conda-forge docs (https://conda-forge.org/#contribute) for example, suggest that if you update a feedstock, you should consider adding yourself as a maintainer. It's been a practice I do, and have done, since the start of my contributions. It's also best practice to remove yourself if you can no longer keep up (as is why I am removed). We pride ourselves in following best practices. I'm really not sure what you're saying with internal deadlines? We are coders who work collaboratively...not sure what assumptions you're making :) But I think all maintainers deserve equal rights in merging. Thanks! Looking forward to getting this merged. |
Thanks @dsangillo for agreeing to maintain the feedstock. I see @h-vetinari's point because @dsangillo was removing a maintainer without any explanation and is a new github account. @dsangillo, in the future when you are removing a maintainer, please add some explanation. |
Any maintainer (account) could take over a feedstock & publish corrupted artefacts. Of course, those can be removed by conda-forge/core, but it needs to be noticed and will have a time lag. Of course, this risk scales with the criticality of the package (e.g. python, openssl, cryptography, numpy, etc.). Here's an example where someone who already maintained 100+ feedstocks was asked to go through PRs rather than maintainership for scipy: conda-forge/scipy-feedstock#188
I think starting with PRs is perfectly reasonable, but in this case, I agree that it's warranted to move forward. Welcome @dsangillo! :) |
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)Closes #12
Closes #11