#2142 Non-responsive maintainer: mflobo
Closed: Accepted 4 years ago by psabata. Opened 4 years ago by amoralej.

@mflobo left cern time ago and he's not longer maintaining packages in OpenStack ecosystem. I tried to contact him both using his personal mail and Fedora ML:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXAAP7SQS2ZD4SMVIXLVTRO4UUSPDZVR/

According to https://src.fedoraproject.org/user/mflobo he's the only maintainer for python-mistralclient, python-congressclient and python-yaql. As these three are somehow related to OpenStack packages, i'd be happy to take them as maintainer.


This is not following the policy yet count me +1 anyway (because the request makes sense).

Metadata Update from @churchyard:
- Issue tagged with: nonresponsive maintainer

4 years ago

Please follow the non-responsive maintainer policy instructions.

@amoralej Any update on following the policy? Are you responsive? :smiling_imp:

Let me re-read the policy, again. I filled bz, i sent direct mails to him and sent a mail to fedora-devel. Sorry, I'm not sure what part of the policy i'm not following.

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Check if the non-responsive maintainer is on vacation.

I'll assume you've done that.

File a bug against the package in Bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must.

Where is this? The issue links to no BZ. The e-mail links to two regular bugzillas that do not look like this at all.

After every 7 days, the reporter adds a comment to the bug report asking again for a response.

Happened in the bugzillas only after the first week.

After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer.

There was no second failed attempt. The was an e-mail send before the first failed attempt anyway.

After other 7 days (now 3 weeks total), the reporter creates a FESCo issue with the bug link.

There is this issue, but sooner than expected, there is no bug link.


The policy clearly says creating a bugzilla is a must. Yet you've just skipped that part altogether.

Sometimes, we assume an existing bugzilla was used for the bumping. This didn't happen either.

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Check if the non-responsive maintainer is on vacation.

I'll assume you've done that.

Done

File a bug against the package in Bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must.

Where is this? The issue links to no BZ. The e-mail links to two regular bugzillas that do not look like this at all.

I opened a bz for the "outstanding issue he needs to address", https://bugzilla.redhat.com/show_bug.cgi?id=1711394", this was closed by one of the provenpackagers but not the maintainer. TBH, i'm not sure if there is anything special in the bz that I'm missing, any special subject or something to make "unresponsive maintainers bz" different to regular BZ.

After every 7 days, the reporter adds a comment to the bug report asking again for a response.

Happened in the bugzillas only after the first week.

After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer.

There was no second failed attempt. The was an e-mail send before the first failed attempt anyway.

After other 7 days (now 3 weeks total), the reporter creates a FESCo issue with the bug link.

There is this issue, but sooner than expected, there is no bug link.

This maintainer has not connected to Fedora in years, this is not the first time i try to connect him. He left his previous job and stop packaging. By the way, the policy also states:

" If there is no known way of contacting the former maintainer, or they are not willing to make the required change in the packagedb, one can short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4."

The policy clearly says creating a bugzilla is a must. Yet you've just skipped that part altogether.
Sometimes, we assume an existing bugzilla was used for the bumping. This didn't happen either.

TBH, i'm not sure if there is anything special in the bz that I'm missing

  1. open a BZ, say: XXX is not responsive, please respond and fix this and this and this
  2. after a week, post: please respond
  3. after a week, post: please respond; send e-mail to devel
  4. after a week, post: please respond; open ticket
  5. get +1; after a week, you're done

Is this tedious? Probably. Did you follow it? No.

This maintainer has not connected to Fedora in years, this is not the first time i try to connect him. He left his previous job and stop packaging.

And that's why I've already said:

This is not following the policy yet count me +1 anyway (because the request makes sense).

Yet if you won't follow the policy, my 1 vote won't make it.

By the way, the policy also states:

" If there is no known way of contacting the former maintainer, or they are not willing to make the required change in the packagedb, one can short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4."

Consider me +1 still.

+1 too, this seems pretty clear cut (even if the policy is not followed precisely).

To avoid future confusion, i suggest to use something like this in similar cases:

I'm making a request to short-circuit the nonresponsive maintainer policy because X, Y and Z.

Metadata Update from @psabata:
- Issue tagged with: pending announcement

4 years ago

https://pagure.io/releng/issue/8492 you own python-mistralclient, python-congressclient and python-yaql

Metadata Update from @psabata:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata