Unresponsive maintainer: Alex Chernyakhovsky

[Robbie Harwood]

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/[e-mail].o...

[Maxwell G]

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

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

[Robbie Harwood]

Maxwell G via devel <devel(a)lists.fedoraproject.org&gt; 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.
>
>  [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy/
>  #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

[Michel Alexandre Salim]

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,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Robbie Harwood]

Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt; 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

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

[Maxwell G]

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.

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

[Vitaly Zaitsev]

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".

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

On 6/29/22 8:45 PM, Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt; 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

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

[Vitaly Zaitsev]

On 29/06/2022 21:23, zebob.m(a)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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

[Maxwell G]

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...

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

[Stephen Smoogen]

On Wed, 29 Jun 2022 at 14:10, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org&gt; 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.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miro Hrončok]

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 ;)

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Stephen Smoogen]

On Wed, 29 Jun 2022 at 14:52, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org&gt; 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.
>
>  


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Carl George]

On Wed, Jun 29, 2022 at 2:30 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; 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(a)easycoding.org)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

-- 
Carl George

[Chris Adams]

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(a)cmadams.net&gt;

[Carl George]

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(a)cmadams.net&gt; 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(a)cmadams.net&gt;
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Carl George

[Carl George]

On Wed, Jun 29, 2022 at 1:09 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; 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(a)easycoding.org)
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Carl George

[Neal Gompa]

On Wed, Jun 29, 2022 at 2:09 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Michel Alexandre Salim]

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,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2