Hi Alex + Fedora,
I'm trying to contact Alex Chernyakhovsky, the maintainer of mosh. Does anyone know how to contact them?
I have started the responsive maintainer process due to lack of contact through bugzilla mail. Specifically, this is about an epel9 branch, which has been repeatedly requested since March (including an offer to maintain the branch) in https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and https://bugzilla.redhat.com/show_bug.cgi?id=2059757 .
Alex, while I regret that we're here a second time [1], please know that it's because we want to use this thing yinz built. If it would be helpful to you, I'm happy to either maintain or help co-maintain mosh.
Per Fedora policy, check bug is: https://bugzilla.redhat.com/show_bug.cgi?id=2101951
Be well, --Robbie
1: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote:
I have started the responsive maintainer process due to lack of contact through bugzilla mail. Specifically, this is about an epel9 branch, which has been repeatedly requested since March (including an offer to maintain the branch) in https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and https://bugzilla.redhat.com/show_bug.cgi?id=2059757 .
You might also be interested in the Stalled EPEL Requests policy[1]. This would've allowed you to get permissions to branch the package for EPEL without going through the non-responsive maintainer process. Of course, if after a certain amount of time, a maintainer is deemed completely non-responsive, you should go through the respective process. The Stalled EPEL Requests policy is just intended to provide a more expedient way to get a package branched for EPEL.
[1]: https://docs.fedoraproject.org/en-US/epel/epel-policy/ #stalled_epel_requests
Maxwell G via devel devel@lists.fedoraproject.org writes:
On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote:
I have started the responsive maintainer process due to lack of contact through bugzilla mail. Specifically, this is about an epel9 branch, which has been repeatedly requested since March (including an offer to maintain the branch) in https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and https://bugzilla.redhat.com/show_bug.cgi?id=2059757 .
You might also be interested in the Stalled EPEL Requests policy[1]. This would've allowed you to get permissions to branch the package for EPEL without going through the non-responsive maintainer process. Of course, if after a certain amount of time, a maintainer is deemed completely non-responsive, you should go through the respective process. The Stalled EPEL Requests policy is just intended to provide a more expedient way to get a package branched for EPEL.
#stalled_epel_requests
Thanks, I didn't know about that. Hopefully I'll never have to use it, but good to know.
In this case, because no one needinfo'd the maintainer, the EPEL policy can be slower (two weeks compared to the minimum ten days for nonresponsive). Also, a literal reading of the EPEL policy says that the same person needs to needinfo as opened the bug, so if that's the case, then it would have been three weeks (because I didn't open either bug), unless I ask one of them to needinfo. I'm not sure if that's intended?
Be well, --Robbie
Hi Robbie,
On Wed, 2022-06-29 at 12:02 -0400, Robbie Harwood wrote:
In this case, because no one needinfo'd the maintainer, the EPEL policy can be slower (two weeks compared to the minimum ten days for nonresponsive). Also, a literal reading of the EPEL policy says that the same person needs to needinfo as opened the bug, so if that's the case, then it would have been three weeks (because I didn't open either bug), unless I ask one of them to needinfo. I'm not sure if that's intended?
I'm not sure that's intended. I'm involved in drafting that policy, and personally would not mind escalating a bug initially opened by someone else.
Thanks for pointing out that the language is a bit unclear, we can probably iterate on this.
Best regards,
On 29/06/2022 01:18, Maxwell G via devel wrote:
You might also be interested in the Stalled EPEL Requests policy[1]. This would've allowed you to get permissions to branch the package for EPEL without going through the non-responsive maintainer process.
This policy looks like a package hijack attempt.
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 29/06/2022 01:18, Maxwell G via devel wrote:
You might also be interested in the Stalled EPEL Requests policy[1]. This would've allowed you to get permissions to branch the package for EPEL without going through the non-responsive maintainer process.
This policy looks like a package hijack attempt.
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Be well, --Robbie
On 29/06/2022 18:47, Robbie Harwood wrote:
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
On Wednesday, June 29, 2022 1:09:07 PM CDT Vitaly Zaitsev via devel wrote:
On 29/06/2022 18:47, Robbie Harwood wrote:
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
I'm a bit confused. You say this sounds like a "package hijack attempt," but then you also say you don't like that it only allows access to epel* branches.
On 29/06/2022 20:24, Maxwell G wrote:
I'm a bit confused. You say this sounds like a "package hijack attempt," but then you also say you don't like that it only allows access to epel* branches.
It is not possible to restrict access to only selected branches. EPEL maintainers can commit to Fedora branches and vice versa.
Thus, the newly added EPEL maintainers can do Fedora updates, and Fedora package maintainer can't prevent this. That's why I called this a "package hijack attempt".
On 6/29/22 8:45 PM, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 29/06/2022 20:24, Maxwell G wrote:
I'm a bit confused. You say this sounds like a "package hijack attempt," but then you also say you don't like that it only allows access to epel* branches.
It is not possible to restrict access to only selected branches. EPEL maintainers can commit to Fedora branches and vice versa.
Thus, the newly added EPEL maintainers can do Fedora updates, and Fedora package maintainer can't prevent this. That's why I called this a "package hijack attempt".
What do you mean it is not possible? Isn't the new "collaborator" role exactly for this?
Best regards,
Ribert-André Mauchin
On 29/06/2022 21:23, zebob.m@gmail.com wrote:
What do you mean it is not possible? Isn't the new "collaborator" role exactly for this?
Yes, didn't know about it. My bad. Thanks for the info.
Collaborator: A user or a group with this level of access can do everything what a user/group with ticket access can do + it can commit to some branches in the project. These branches are defined here using their name or a pattern and needs to be comma separated.
If the new co-maintainers are added as collaborators with an epel* mask, I'm fine with that.
On Wednesday, June 29, 2022 1:24:07 PM CDT Maxwell G via devel wrote:
On Wednesday, June 29, 2022 1:09:07 PM CDT Vitaly Zaitsev via devel wrote:
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
I'm a bit confused. You say this sounds like a "package hijack attempt," but then you also say you don't like that it only allows access to epel* branches.
Ah, I misread "can make any changes" as "can't make any changes," as maintainers added through this process are only given collaborator access to epel* branches. That explains why I was confused...
On Wed, 29 Jun 2022 at 14:10, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
On 29/06/2022 18:47, Robbie Harwood wrote:
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
Yes, they can. So can a lot of other people and things in Fedora. This isn't other distros where a package maintainer is a defacto dictator of the package they put into the OS. There is a give and take in what can happen with a package.
On 29/06/2022 20:32, Stephen Smoogen wrote:
Yes, they can. So can a lot of other people and things in Fedora.
Only proven-packagers in limited situations or people who have been granted access by the package owner.
This isn't other distros where a package maintainer is a defacto dictator of the package they put into the OS. There is a give and take in what can happen with a package.
But it is. The package owner has full control over the package and can add or remove co-maintainers as they see fit.
But now we see that someone can add other people to co-maintainers. This is terrible.
On 29. 06. 22 20:50, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:32, Stephen Smoogen wrote:
Yes, they can. So can a lot of other people and things in Fedora.
Only proven-packagers in limited situations or people who have been granted access by the package owner.
This isn't other distros where a package maintainer is a defacto dictator of the package they put into the OS. There is a give and take in what can happen with a package.
But it is. The package owner has full control over the package and can add or remove co-maintainers as they see fit.
But now we see that someone can add other people to co-maintainers. This is terrible.
No, it isn't. It's great ;)
On Wed, Jun 29, 2022 at 09:23:10PM +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 20:58, Miro Hrončok wrote:
No, it isn't. It's great ;)
Why? I doubt fighting maintainers is a good thing for Fedora.
Why are you assuming the added EPEL maintainers want to fight the existing maintainers. That's an unwarranted negative viewpoint. People aren't asking to be EPEL maintainers with malicious intent to hijack a package, they are working to try to benefit the Fedora project in cases where the existing maintainer doesn't want to get involved in EPEL maint work.
After demonstrating their skills in EPEL maint the main package maintainer may choose to invite them to get involved in Fedora branch maint too. Spreading the load is a very good thing, since so many package maintainers in Fedora are over-stretched in what they try to cope with. Reducing the bus factor is a good backup for time periods when real life prevents a maintainer doing work on Fedora.
We should be openly welcoming people who want to get involved in EPEL, and assume positive intent by default because that will be the overwhealming common case.
With regards, Daniel
On Wed, 29 Jun 2022 at 14:52, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
On 29/06/2022 20:32, Stephen Smoogen wrote:
Yes, they can. So can a lot of other people and things in Fedora.
Only proven-packagers in limited situations or people who have been granted access by the package owner.
This isn't other distros where a package maintainer is a defacto
dictator of the package they put into the OS. There is a give and take in what can happen with a package.
But it is. The package owner has full control over the package and can add or remove co-maintainers as they see fit.
I believe the term 'package owner' was killed several years ago in Fedora. Maintainers are custodians and do not own the package.
But now we see that someone can add other people to co-maintainers. This is terrible.
On 29/06/2022 21:06, Stephen Smoogen wrote:
Maintainers are custodians and do not own the package.
This becomes true with the new EPEL policy. I think it should be revisited to follow Fedora's non-responsive maintainer procedure with an explicit FESCo approval on a case-by-case basis.
On Wed, Jun 29, 2022 at 2:30 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 29/06/2022 21:06, Stephen Smoogen wrote:
Maintainers are custodians and do not own the package.
This becomes true with the new EPEL policy. I think it should be revisited to follow Fedora's non-responsive maintainer procedure with an explicit FESCo approval on a case-by-case basis.
It was true before the EPEL stalled policy. Fedora is all of our distribution. No one owns packages, we maintain them.
Requiring FESCo sign off for this on every package would significantly hamper EPEL growth. We're not going to do that.
The origin of this policy is that the full unresponsive maintainer process is overkill for getting a package added to EPEL. Maintainer1 shouldn't have to suggest that all of maintainer2's packages be orphaned or assigned to themselves in order to be added as a collaborator on an EPEL branch.
If you don't like the policy, then you can avoid it simply by handling EPEL branch requests promptly (faster than 3 weeks).
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Jumping in on this... I opened BZ 2095512 a few weeks ago about getting pure-ftpd for EPEL 9, with a follow-up a week ago. There's already an EPEL 8 branch, so I guess that maintainer was notified (or do all get notified)?
Looking at src.fedoraproject.org, it doesn't look like any of the maintainers have been active in a bit, and the only pure-ftpd changes in a while have been rebuilds and such. There's been a couple of new upstream releases (one just last week), noted in BZ 2026153, with no update to the Fedora or EPEL packages... wondering if any of the maintainers are still active.
What's the correct approach here? I'd need to look at the package to see if I'd be interested in taking it on (my BZ request so far was just to ask for the existing maintainers to branch it).
If you're happy with the current version 1.0.49 from rawhide being branched for epel9, then the stalled process would be a good fit. With collaborator permissions on epel* branches, you can request the epel9 branch, merge commits from rawhide to epel9, create builds, and create bodhi updates.
If you're interested in helping with the long term maintenance of the package, to include getting it updated to the latest version (perhaps before building it for epel9 so that package can start on the latest version), then it's worth considering the unresponsive maintainer process.
On Wed, Jun 29, 2022 at 3:51 PM Chris Adams linux@cmadams.net wrote:
Jumping in on this... I opened BZ 2095512 a few weeks ago about getting pure-ftpd for EPEL 9, with a follow-up a week ago. There's already an EPEL 8 branch, so I guess that maintainer was notified (or do all get notified)?
Looking at src.fedoraproject.org, it doesn't look like any of the maintainers have been active in a bit, and the only pure-ftpd changes in a while have been rebuilds and such. There's been a couple of new upstream releases (one just last week), noted in BZ 2026153, with no update to the Fedora or EPEL packages... wondering if any of the maintainers are still active.
What's the correct approach here? I'd need to look at the package to see if I'd be interested in taking it on (my BZ request so far was just to ask for the existing maintainers to branch it).
-- Chris Adams linux@cmadams.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Jun 29, 2022 at 1:09 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 29/06/2022 18:47, Robbie Harwood wrote:
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
This is false. The EPEL stalled process results in the new maintainer being added as a collaborator on branches matching the epel* pattern.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Jun 29, 2022 at 2:09 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 29/06/2022 18:47, Robbie Harwood wrote:
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
They cannot unless they have some other way to get the access already. EPEL maintainers are added as collaborators on epel branches only through this policy.
On Wed, 2022-06-29 at 20:09 +0200, Vitaly Zaitsev via devel wrote:
On 29/06/2022 18:47, Robbie Harwood wrote:
I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs.
Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that.
Rest assured, they cannot. The escalation process specifically documents granting the newly added maintainers collaborator access only on epel* branches.
We actually made sure collaborator support is properly working before we document this policy.
Best regards,