(Some fo the listed packages are probably half retired, as they don't get Koji builds, but they exist in git (such as python-django14 or python-django15). We need to retire those in git properly as well.)

I'm willing to take python-rply, cpptest, httrack. dokuwiki should be assigned to @suve since he was asking about this in releng ticket.

I'm willing to take python-rply, cpptest, httrack. dokuwiki should be assigned to @suve since he was asking about this in releng ticket.

I re-assigned those packages. Another issue with some of these orphaned packages is that there are still co-maintainers assigned for these packages. So I guess they should either removed from the packages (if they do not care about the package) or they need to be reminded stronger to adopt their packages.

The technical details to revive retiring the packages should be coordinated with releng. If pagure does not yet provide the info about when a package was orphaned I would prefer to get it added there instead of working around it in the long term. Maybe @pingou knows a method to figure this out.

The technical details to revive retiring the packages should be coordinated with releng. If pagure does not yet provide the info about when a package was orphaned I would prefer to get it added there instead of working around it in the long term.

Before we do that, here's a temporary workaround: https://github.com/hroncok/fedora-orphaned-packages

Hmmmmmmmmm. Taking the first package from the list:
https://src.fedoraproject.org/rpms/bcg729 – smain - main admin
but pagure_owner_alias.json says

"bcg729": [
            "orphan"
        ],

This package was created 8 months ago by smani, I doubt it could have been even temporarily orphaned in the meantime.

Next: php-mongodb: Remi Collet (remi) - main admin, pagure_owner_alias.json says orphan.
purple-hangouts same
8Kingdoms - retired
915resolution - retired
AcetoneISO2 - retired

I don't know if this is some caching, but the results seem partially bogus.

Anyway, after looking at the pagure web interface, and the api docs (https://pagure.io/api/0/), I don't see anything that'd show when orphaning or other ownership changes took place. Pagure developers: is this information available somehow? We need to start the orphaning procedure again quickly. I'd try to write a script to do the orphaning, but I don't see the necessary ownership data anywhere.

For the not-orphaned packages I've opened https://pagure.io/fedora-infrastructure/issue/7192

For the retired ones listed, this should help: https://pagure.io/fedora-misc-package-utilities/pull-request/6

@zbyszek The JSON file has the namespace as first keys, the top one is container, rpms is lower down. (see https://pagure.io/fedora-infrastructure/issue/7192#comment-528022)

From the FESCo meeting today:

  * AGREED: The plan is: 1. contact factory 2 to see if they want to
    finish the script, 2. once the script is ready, send info to all
    co-maintainers and fedora-devel, 3. after a week reassign to one
    co-maintainer, if no co-maintainers, retire (+6, 0, 0)  (contyk,
    15:46:58)

I'm leaving this open to track the actions.

The script is available here:
https://pagure.io/releng/pull-request/6895

The script seems to work with the limitation that there is no per-branch orphan status.

1. after a week reassign to one co-maintainer, if no co-maintainers, retire

There is a bunch of maintainers who are deemed non-responsive. We probably shouldn't reassign any new packages to them.

We have gone through the non-responsive procedure in FESCo about 80 times (at least in the period visible in https://pagure.io/fesco/issues). Most often the outcome is "yes, maintainer non-responsive, reassign packages", but not always (sometimes it's "I missed my mail", sometimes it's "let me get rid of some packages, keep the rest"). Exclusion from reassignment should only apply to the maintainers in the first category.

The list of relevant tickets is:
https://pagure.io/fesco/issues?status=all&search_pattern=responsive
https://pagure.io/fesco/issues?status=all&tags=nonresponsive+maintainer
(I created tag "nonresponsive maintainer" to tag the tickets which don't fit the search pattern.)
But as noted above, not all tickets have the same outcome.

IMHO, before doing reassignment, we should make a list of non-responsive maintainers and not assign new packages to them.

FTR: Till's announcement of the list of orphan packages: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2O2PTTYRY73QCG452HC5CO4CPUTQX3FA/

IMHO, before doing reassignment, we should make a list of non-responsive maintainers and not assign new packages to them.

In general I would welcome some kind of cleanup step for co-maintainers to ensure that the maintenance status is better visible.

Thank you for posting the link. Regarding the owner change history, it seems that fedmsg/datagrepper does not have a message for owner changes anymore. At least https://apps.fedoraproject.org/datagrepper/raw?package=dzen2 does not show a change from yesterday.

Thank you all for restarting this procedure!

If there really is no fedmsg I suspect that there was no notification for package maintainers that their package was orphaned. Therefore I would strongly prefer to wait longer than just a week before starting to retire packages. I propose to wait for six weeks, which would be the regular waiting time after announcement.

IMHO, before doing reassignment, we should make a list of non-responsive maintainers and not assign new packages to them.

In general I would welcome some kind of cleanup step for co-maintainers to ensure that the maintenance status is better visible.

+1. Last time I went through the "non-responsive maintainer" policy, the package was at the end reassigned to another inactive maintainer instead of me. That was very disappointing.

Also, the package should not be assigned to group IMO.

As discussed in the open floor, I asked to re-assign the currently orphaned packages by releng:
https://pagure.io/releng/issue/7812

Dropping the "meeting" tag. There's nothing to discuss right now.

So there is http://src.fedoraproject.org/rpms/python2-matplotlib a dummy package for epel that brings in python-matplotlib.

Now I requested to unretire it on Fedora, so we can package actual python2-matplotlib package there (matplotlib 3 does not support Python 2, so we need to split the package).

Let's say I orphan it later. It gets reassigned to @tibbs who cannot do anything else than to orphan it entirely. The per branch status is important here. How do I prevent the package to be autoassigned to @tibbs? How would I orphan it on Fedora only without disturbing EPEL?

Retiring a branch is different from orphaning a package. And we no longer have the ability to have differing maintainers between EPEL and Fedora (which means that I have ended up being responsible for EPEL packages I never wanted, but that's a separate issue).

So if the Fedora python2-matplotlib thing goes away, you just retire rawhide and eventually once all of the relevant Fedora releases have gone EOL, you remove yourself from the package repo. I don't think you would ever want to orphan the package.

I don't want to retire a branch. I want to get the package in and orphan it after, for the other maintainers to pick it up. But if I do so, you end up maintaining it but this "comaintainers get it" rule. That's what I'm pointing at.

What would be the utility of that? The people maintaining the package should be the one to get it set up. Importing something only to immediately orphan it seems either pointless or like someone is trying to get around some other policy.

In any case, there is no separation between EPEL and Fedora maintainers. You simply cannot orphan something for Fedora only. You can only remove yourself as a maintainer, leaving me. If you want me to give access to someone in particular, it seems like asking me to do that would be the simplest thing instead of trying to do anything involving orphaning the package.

I brought this up in the Open Floor at today's FESCO meeting because it seemed relevant to an issue with python2-matlib being orphaned and retired when it was meant to be an EPEL only stub package before. Currently the orphan/retire policy seems to have problems with the following 'corner cases'

1. A package is in EPEL but not in Fedora.
2. A package was in EPEL but is no longer but is still in Fedora.

There may be some other corner cases, but in any case.. there seems to have been a lack of coordination.

I brought this up in the Open Floor at today's FESCO meeting because it seemed relevant to an issue with python2-matlib being orphaned and retired when it was meant to be an EPEL only stub

One important distinction between orphaned and retired status is that packages can be retired on a specific branch but can only be orphaned completely. Regarding python2-matplotlib there was some extra confusion because it was initially an EPEL-only package and then briefly also a Fedora package as far as I understand.

package before. Currently the orphan/retire policy seems to have problems with the following 'corner cases'

A package is in EPEL but not in Fedora.

Then it will be retired in Rawhide. If it is orphaned, the reports for orphaned packages in Rawhide should not mention it, since it is retired. It would be reported in EPEL reports, if there were be any.

A package was in EPEL but is no longer but is still in Fedora.

Then it will be reitred in EPEL. If it is orphaned, it will be reported in the Rawhide orphan pkgs reports, when they are created.

AFAICS, the confusion for @tibbs comes from missing notifications about package owner changes and probably a problem when packages that are not orphaned are unretired for a specific branch. This will probably unintentionally reset the main admin since this case is very likely not handled especially.

This will probably unintentionally reset the main admin since this case is very likely not handled especially.

It is handled especially but it is a manual process, therefore I would assume that a mistake led to this. Here is the detailed process:
https://docs.pagure.org/releng/sop_unretire.html#verify-package-is-not-orphaned

I've outlined what happened with python2-matplotlib here:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YYGEUDXNIECN7LW5CQBOOEDIYQ5ODSKT/#KTX3G7RB4TTDP7UV6ABBUTVWENS4UZYK

What is the status on this ticket? Do we still need an implementation to solve this problem going forward?

@churchyard would like us to discuss this one today. The meeting starts at 15:00UTC in #fedora-meeting-1 on irc.freenode.net.

What would you like to discuss @churchyard - is there any new info?

I'd like to talk to FESCo about what an individual is allowed to do, how can we help and what is possible to do to unblock this.

We agreed to two things regarding this ticket in today's meeting:

AGREED: The policy to retire packages after six weeks of being orphaned is reaffirmed. At least three warnings with one-week intervals will be sent out to co-maintainers before retiring. (+7, 0, -0)
AGREED: mhroncok is added as a release engineer to process unretirement requests (which are still the same process as now, file ticket, it gets checked, etc) (+6, 1, -0)

Additionally, @churchyard agreed to an action:

ACTION: mhroncok volunteers to retire the packages manually and see what can be automated

Shall we keep this ticket open until it is implemented?

Shall we keep this ticket open until it is implemented?

Works for me.

Miro sent out the first email last Friday [1]. There has been some discussion and 8 unorphan requests to releng [2]. We need to wait another three weeks and the current backlog shall be gone. The question is how to automatize this.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X77IOA2RE3KADMMVPISYSESA3KYJ2UFR/
[2] https://pagure.io/releng/issues?status=all&search_pattern=orphan (I don't see a way to filter by date in pagure.)

Please advise:

• The policy only says "Orphan packages will be retired if they remain orphaned for six weeks."
• The e-mail template from https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py says:

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

When the time comes, should I retire dependent packages?

On Thu, 2018-12-13 at 09:38 +0000, Miro Hron=C4=8Dok wrote:

When the time comes, should I retire dependent packages?

I don't see a way to avoid that - if one of your dependencies is
retired then your package will be broken. I guess we could consider
applying a FTBFS type of policy to these broken packages.

Another option might be to send an e-mail to dependent packagers to
tell them "warning: your dependency $x has been retired, you have $n
days to act or your package will also be retired."

One thing I thought might help in the orphaned packages e-mails is to
indicate which of my packages depend on the packages being retired.
Since the list is so long, I was on it for one package as a co-
maintainer (and I don't use it so I plan to let it slip), but what I
wasn't sure about was whether I was also CC'd on the e-mail because I
have a dependent package.

I think that doing something about dependent packages is good. However I don't feel like there is a policy for it and I'd rather not take action based just on what I feel.
Do we need another policy?

One thing I thought might help in the orphaned packages e-mails is to
indicate which of my packages depend on the packages being retired.

See the Affected (co)maintainers section for the list of packages that are to be retired.

Go trough the detailed list (omitted from the e-mails for now as they are very long, but uploaded to fedorapeople and linked from the e-mail) and search for the package.

See for example you:

bowlofeggs: python-pyramid-chameleon

Search for python-pyramid-chameleon:

python-pyramid-chameleon bowlofeggs, infra-sig, orphan, python-sig 41 weeks ago

It is orphaned and you are a co-maintainer.

But see for example caolanm:

caolanm: hunspell-de, ...

Search for hunspell-de:

hunspell-de orphan 39 weeks ago

No comaintainers, search further....

Depending on: hunspell-de (2), status change: 2018-03-07 (39 weeks ago)
    ibus-typing-booster (maintained by: anishpatil, mfabian)
        ibus-typing-booster-2.3.1-1.fc30.src requires hunspell-de = 0.20161207-2.fc29

    libreoffice (maintained by: caolanm, dtardon, erack, sbergmann)
        libreoffice-langpack-de-6.1.2.1-7.fc30.i686 requires hunspell-de = 0.20161207-2.fc29

Oh, here it is, the problem is in libreoffice. (That'll be fun retiring!)

Another possibility si to search for the username directly and see all locations.

On Fri, 2018-12-14 at 09:47 +0000, Miro Hron=C4=8Dok wrote:

Go trough the detailed list (omitted from the e-mails for now as they
are very long, but uploaded to fedorapeople and linked from he e-mail) and
search for the package.

Ah very nice, that addresses my question for sure, thanks!

I agree that our policy does not very well address your questions:

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

It really just describes what they are, not what should happen to them
if they stay orphaned forever. It does kinda hint that the general
Fedora community is responsible for them, though I expect that means
they don't get much attention.

Proposal to kick things off: If an orphaned package has dependencies, a
targeted e-mail is sent to the maintainers of those dependent packages
telling them that their package is in danger of being removed if one of
them does not volunteer to maintain the orphaned package. If at the end
of the six weeks nobody has volunteered, we repeat the process with the
dependent packages of the first set of dependent packages. We repeat
this loop until all options are used up or until the orphaned package
is adopted. If all options are used up, the entire chain of
dependencies is retired.

Now that I've written that, I'm afraid it's too complicated to
describe, and that means to understand, and probably to implement as
well. Here's a simpler proposal:

Proposal #2: If an orphaned package is not adopted after 6 weeks, it is
retired regardless of dependent packages. Those dependent packages will
be broken, and the FTBFS policy will take care of them the next time a
mass rebuild happens.

This one is simpler, but also kinda harsh. Simple can be good though.

Thoughts?

Simple is good.

A periodic remainder about broken dependencies (used to happen, doesn't now) and broken build dependencies (probably never happened) would of course be even better.

I have a simpler counterproposal: if the orphaned package has dependencies, we automatically file FTBFS bugs for those packages, and follow the normal FTBFS procedure there.

Why? I think it's good to reuse existing policy. A missing build dependency is like any other FTBFS bug, not of very high priority, if the package doesn't have other bugs. Also, I feel that more people might look at a FTBFS bug: I go through the list occasionally, looking for packages to build. If it is clear that the FTBFS bug is because of a retired dep, in many cases it's for some optional functionality, and a drive-by contributor can see fix this without too much work.

EDIT: oh, of course this is very similar to what bowlofeggs wrote. The difference is that my suggestion is to file a FTBFS bug immediately. I think that's better.

On Fri, 2018-12-14 at 15:40 +0000, Zbigniew J=C4=99drzejewski-Szmek wrote:

I have a simpler counterproposal: if the orphaned package has
dependencies, we automatically file FTBFS bugs for those packages,
and follow the normal FTBFS procedure there.

I like this. My only thought is that sometimes dependencies aren't
build dependencies, so it's possible that the packages does build from
source even though it does not install. FTI (Failed to Install) policy
needed too?

Why? I think it's good to reuse existing policy. A missing build
dependency is like any other FTBFS bug, not of very high priority, if
the package doesn't have other bugs. Also, I feel that more people
might look at a FTBFS bug: I go through the list occasionally,
looking for packages to build. If it is clear that the FTBFS bug is
because of a retired dep, in many cases it's for some optional
functionality, and a drive-by contributor can see fix this without
too much work.

Yeah I like the idea of reusing existing policy too. Keeping things as
simple as possible is a good goal. We don't want to end up like
Alabama's state constitution. See the end of:

http://loweringthebar.net/2018/11/injured-by-constitution.html

That's why we need gating! Then FTI would be just another variant of FTBFS. But more seriously, I wouldn't worry about it. Let's open a FTBFS bug, and the maintainers can hash it out.

The mass rebuild is scheduled for 2019-01-30.

So after I retire the first batch, I think the best course of action would be to wait for that to happen.

IMHO the dependent packages should be retired when the orphaned packages are retired to keep the repositories consistent. Not being able to install a package that is in the repo is IMHO a worse user experience than not shipping the broken package since it will not waste time on figuring out why the package won't install. Also it allows to easily use the proper retirement reason (the dependency was orphaned) instead of a generic reason.

The releng sop also highlights that broken deps should be avoided:
https://docs.pagure.org/releng/sop_retire_orphaned_packages.html

If there are high profile packages that should not be retired (i.e. libreoffice), then the maintainers should be approached manually to ensure that they take care of the package.

Waiting for 2-3 more months to retire the broken packages does not really serve us IMHO.

Either way, the orphaned/retire policy is not clear on the subject.

There are build dependencies (= package FTBFS, but it does not harm the user experience yet) and runtime dependencies (harms the user experience immediately).

Should we have a general policy for broken runtime dependencies, or just ensure this is covered by the orphaned/retired policy?

It is in theory part of the releng schedule to notify and retire packages with broken dependencies prior to braching:
https://fedorapeople.org/groups/schedule/f-30/f-30-releng-tasks.html

In practice there is AFAIK no reminder system and therefore it is easily forgotten.
However, when releng is retiring packages, the usual procedure was/is to not leave broken dependencies behind (not only for retiring orphaned packages but also for retiring FTBFS packages).

An official FESCo approved decision about dependent packages has not been made.

Adding to the meeting agenda for Monday 2019-01-21.

Looks like the current report can't find any of the .i686 deps in the x86_64 repo, making the report really long and possibly not correct. ;(

I'll summarize what we talked about on the meeting today. In the meantime, here are the minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-04/fesco.2019-02-04-15.01.html

This was discussed during today's meeting:
ACTION: mhroncok to draft a policy update proposal

Draft not ready yet for this meeting, sorry about that :(

Closing in favor of https://pagure.io/fesco/issue/2109

The original problem is somehow solved, so closing as accepted.