#1771 Unresponsive maintainer: kanarip
Closed: Fixed 7 years ago Opened 7 years ago by vondruch.

@kanarip (Jeroen van Meeuwen) is more or less unresponsive. There were several attempts to apply the nonresponsive policy to him:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQGCB4LXAPTV745QWFGMZQVYMKYJ53D2/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WI7P65RWHIQZLDAV5B5GCIFDU76RRIW6/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GZC46YBXQKJUEUP2ICB5GHCYPOZ64K4V/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/66OHR47FGRFULY22X6ZTFQQ6U5EU4RDM/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DEVAOUC4ILMAZAM2O27NY2V7LJ4DFIAP/

but he always just shows up to say he is alive and therefore the procedure is never finished. Although I saw him last year at Flock and I know he did some reviews, he does not really care about his packages:

https://koji.fedoraproject.org/koji/userinfo?userID=438

Last build is from 2013, more then 4.5 years ago. Several of his packages are abandoned and should be removed from Fedora ages ago, other are maintained by comaintainers or prove packagers.

His unresponsiveness is doing disservice to the whole community. Please release the packages he owns and let others to pick them up or let them be removed from Fedora.


Just FTR, this is list of his packages which failed F26 mass rebuild:

https://kojipkgs.fedoraproject.org/mass-rebuild/f26-failures.html

Most of them are failing for some time already.

BTW somebody could update the Wiki, since these steps are outdated:

Open a ticket in the FESCo trac instance with the maintainers FAS account CC'ed. Add the 'meeting' keyword.

Fesco has no trac and I can't add 'meeting' tag neither CC anybody ... actually, I could probably reference @kanarip this way ....

This is pretty much a clear example of when the exception procedure should be followed. From that link: "Examples include when [...] maintainer response prevents the nonresponsive process from proceeding without actually resuming maintenance."

I'm +1 to orphaning all packages maintained by @kanarip at this time. If he becomes responsive again, he can ask to become a comaintainer.

Metadata Update from @sgallagh:
- Issue tagged with: meeting

7 years ago

I am also a +1 to @sgallagh's proposal.

+1 to orphaning @kanarip's packages. Given that he stated in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DJ776OTLRCHBKDRT7THWKYGZUSQW7S2V/ that he relies on @vondruch maintaining his ruby packages but @vondruch opened the ticket here, I doubt that the current situation is useful or sustainable. Also he does not seem to provide any reason why he wishes to continue being the formal owner or any indication that he is going ot become the primary maintainer.

BTW somebody could update the Wiki, since these steps are outdated:

Open a ticket in the FESCo trac instance with the maintainers FAS account CC'ed. Add the 'meeting' keyword.

Fesco has no trac and I can't add 'meeting' tag neither CC anybody ... actually, I could probably reference @kanarip this way ....

I gave it a shot. Is it possible for you to add the meeting tag after the ticket was created or is it not possible at all for you?

I think only the repo maintainers have permission to set keywords (which makes more sense than the current wiki policy, as we may choose to defer its inclusion in a meeting for one or more weeks depending on the ticket). However, I added the meeting keyword for this topic so we can cover it this week.

I gave it a shot. Is it possible for you to add the meeting tag after the ticket was created or is it not possible at all for you?

The only metadata I am allowed to edit ATM are "Status" and "Closed as". BTW some referenced this to Pagure tracker would be useful IMHO (although it might get obsoleted one day ;)).

BTW some referenced this to Pagure tracker would be useful IMHO (although it might get obsoleted one day ;)).

Although there is the reference to "meeting". Ok, it might work ...

This issue will be discussed in tomorrow's FESCo meeting, 2017-09-08 at 16:00:00 UTC in #fedora-meeting on Freenode.

Forgot to say that I am willing to take over all hist ruby* packages and see what can I do about them. Either I'll fix them, retire or orphan, what will be appropriate ...

I may have to leave before the FESCo meeting finishes... if so, consider me +1 to orphaning/reassigning kanarip's packages.

FESCo agreed during today's meeting that all of @kanarip's packages will be orphaned. @till has volunteered to perform the task, so I will assign this ticket to him.

https://meetbot-raw.fedoraproject.org/fedora-meeting/2017-09-08/fesco.2017-09-08-16.00.txt

Metadata Update from @bowlofeggs:
- Issue assigned to till

7 years ago

Just a quick status update, this is what is supposed to happen:

rpms/dh-make will be given to oron
rpms/facter will be given to gchamoul
rpms/grib_api will be given to jdekloe
rpms/jansson will be given to jirka
rpms/libkolab will be given to orphan
rpms/libkolabxml will be given to orphan
rpms/perl-GO-TermFinder will be given to orphan
rpms/perl-Net-IMAP-Simple will be given to orphan
rpms/perl-Net-IMAP-Simple-SSL will be given to orphan
rpms/perl-Net-Telnet will be given to orphan
rpms/perl-XML-FeedPP will be given to orphan
rpms/perl-XML-TreePP will be given to jehane
rpms/publican-genome will be given to orphan
rpms/puppet will be given to domcleal
rpms/python-ldap will be given to alexl
rpms/revisor will be given to baard
rpms/ris-linux will be given to orphan
rpms/ruby will be given to jstribny
rpms/rubygem-arrayfields will be given to stahnma
rpms/rubygem-attributes will be given to stahnma
rpms/rubygem-builder will be given to jstribny
rpms/rubygem-columnize will be given to stahnma
rpms/rubygem-cucumber will be given to clalance
rpms/rubygem-facets will be given to stahnma
rpms/rubygem-fattr will be given to stahnma
rpms/rubygem-ferret will be given to orphan
rpms/rubygem-gemcutter will be given to stahnma
rpms/rubygem-git will be given to stahnma
rpms/rubygem-hawler will be given to orphan
rpms/rubygem-highline will be given to jamielinux
rpms/rubygem-main will be given to orphan
rpms/rubygem-markaby will be given to orphan
rpms/rubygem-mocha will be given to bkabrda
rpms/rubygem-pervasives will be given to orphan
rpms/rubygem-picnic will be given to orphan
rpms/rubygem-polyglot will be given to lkundrak
rpms/rubygem-rack will be given to jaruga
rpms/rubygem-rake will be given to mtasaka
rpms/rubygem-restr will be given to orphan
rpms/rubygem-reststop will be given to orphan
rpms/rubygems will be given to mtasaka
rpms/rubygem-shoulda will be given to stahnma
rpms/ruby-RRDtool will be given to orphan
rpms/spin-kickstarts will be given to bruno
rpms/sysklogd will be given to orphan

However, the script for this is currently not working right now. I will post an update when I know more.

@till this is hardly the right solution.

@stahnma is inactive already for some time [1], @jstribny is not very active since he left Red Hat, @bkabrda does not maintain his Ruby packages since he moved to Python and to other challenges and I could probably continue ...

[1] http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBUPHRBDMQTF44FJX2ABXCIVDMKV3SXP/

Metadata Update from @maxamillion:
- Issue untagged with: meeting

7 years ago

i'll maintain libkolabxml and libkolab, if they are otherwise orphaned.

revisor can be orphaned -- baard has no interest in this.

the remainder is agreed.

I would volunteer to take libkolabxml and libkolab.
I am happy for @kanarip to be co-maintainer.

@till this is hardly the right solution.
@stahnma is inactive already for some time [1], @jstribny is not very active since he left Red Hat, @bkabrda does not maintain his Ruby packages since he moved to Python and to other challenges and I could probably continue ...

What is your proposal to do instead? Currently the script we have at releng selects one of the other owners to become the new owner: https://pagure.io/releng/blob/master/f/scripts/distgit/orphan-all-packages.py or orphan if there is nobody else.

I thought that the decision was: "FESCo agreed during today's meeting that all of @kanarip's packages will be orphaned."

Let's not make it personal, dear Mr. steal-maintenance-as-dayjob-from-underneath-me.

Are they not just saying the script would work one way, to which you said it's, and I quote, "hardly the right solution"? If anything, you're obstructing my obsolescence. Have some self-pity, but stop blaming others.

I thought that the decision was: "FESCo agreed during today's meeting that all of @kanarip's packages will be orphaned."

Technically they are oprhaned and immediately adopted ;-) AFAIK with the current setup adopting packages is not a self-service feature anymore, therefore releng would need to handle extra manual requests for all orphaned packages to give them to new owners. If there are already co-maintainers it is IMHO valid to expect that they will figure out who will be the new primary point of contact by themself. Also I would say that if there are other co-maintainers who actually moved on it would be best to remove them from the packages to properly communicate the actual situation. Therfore I wold like to start with the first run of the script and then handle individual package problems afterwards.

libkolabxml and libkolab went to @tpokorra and the other packages as follows:

Giving rpms/dh-make to sergiomb
Giving rpms/facter to gchamoul
Giving rpms/grib_api to jdekloe
Giving rpms/jansson to jirka
Giving rpms/libkolabxml to orphan
Giving rpms/perl-GO-TermFinder to orphan
Giving rpms/perl-Net-IMAP-Simple to orphan
Giving rpms/perl-Net-IMAP-Simple-SSL to orphan
Giving rpms/perl-Net-Telnet to orphan
Giving rpms/perl-XML-FeedPP to orphan
Giving rpms/perl-XML-TreePP to jehane
Giving rpms/publican-genome to orphan
Giving rpms/puppet to skottler
Giving rpms/python-ldap to johnp
Giving rpms/revisor to orphan
Giving rpms/ris-linux to orphan
Giving rpms/ruby to mmorsi
Giving rpms/rubygem-arrayfields to orphan
Giving rpms/rubygem-attributes to orphan
Giving rpms/rubygem-builder to tdawson
Giving rpms/rubygem-columnize to orphan
Giving rpms/rubygem-cucumber to mmorsi
Giving rpms/rubygem-facets to orphan
Giving rpms/rubygem-fattr to orphan
Giving rpms/rubygem-ferret to orphan
Giving rpms/rubygem-gemcutter to orphan
Giving rpms/rubygem-git to stevetraylen
Giving rpms/rubygem-hawler to orphan
Giving rpms/rubygem-highline to tdawson
Giving rpms/rubygem-main to orphan
Giving rpms/rubygem-markaby to orphan
Giving rpms/rubygem-mocha to skottler
Giving rpms/rubygem-pervasives to orphan
Giving rpms/rubygem-picnic to orphan
Giving rpms/rubygem-polyglot to vondruch
Giving rpms/rubygem-rack to jaruga
Giving rpms/rubygem-rake to vondruch
Giving rpms/rubygem-restr to orphan
Giving rpms/rubygem-reststop to orphan
Giving rpms/rubygems to vondruch
Giving rpms/rubygem-shoulda to tdawson
Giving rpms/ruby-RRDtool to orphan
Giving rpms/spin-kickstarts to vpavlin
Giving rpms/sysklogd to orphan

Metadata Update from @till:
- Issue close_status updated to: Fixed

7 years ago

Just a short follow-up: I noticed @kanarip was also the owner of some EPEL branches/bugzilla contact for some EPEL branches. I requested this to be changed as well:
https://pagure.io/releng/fedora-scm-requests/pull-request/1820

Well, you mention EPEL, but it does not look like the BZ was updated at all looking at:

https://bugzilla.redhat.com/show_bug.cgi?id=1383539

Tried the "Reset Assignee to default for component" and nothing changed ...

Log in to comment on this ticket.

Metadata