Since FESCo decided on the recent orphan/retirement policies, I guess the general procedure should be discussed there. Removing all the commiters etc might make sense and someone needs to implement this for pagure.

I don't think FESCo can be helpful when discussing the implementation details of retirement. Essentially, when somebody says "fedpkg retire foo", foo should be gone, whatever that means.

I think it is reasonable to remove committers. On the one hand, existing committers are obviously not interested in the package. And if the package is ever unretired, we expect to put in a new set of committers. On the other hand, removing existing committers — and in particular groups — helps ensure that no accidental modifications will be pushed.

@vondruch are there any particular issues that the lack of ACL removal causes? For example unwanted mails, or notifcations, or listing of the package in some publicly visible list, etc.

@vondruch are there any particular issues that the lack of ACL removal causes? For example unwanted mails, or notifcations, or listing of the package in some publicly visible list, etc.

Probably all of this. But the way I came to report this issue is that in Pagure, I am reported as maintainer of rubygem-acts-as-taggable-on. IOW I don't want rubygem-acts-as-taggable-on to be listed here: https://src.fedoraproject.org/user/vondruch/projects

However, one thing I realized is that previously, it was possible to retire the package just for specific branches and to manage ACLs per branch. It is not possible now AFAIK. That might be the reason, why the group is still listed as maintainer of the package. But will it be ever corrected? I don't think so, but I might be mistaken.

I don't think FESCo can be helpful when discussing the implementation details of retirement. Essentially, when somebody says "fedpkg retire foo", foo should be gone, whatever that means.

fedpkg retire foo will retire the particular branch, one can do this for the master branch for an EPEL only package and the expectation would be that the committers stay, since they still need to manage EPEL packages. retiring an orphaned package is a special case here.

Whether or not committers are removed is less a technical decision (implementation detail) but a policy question, therefore FESCo makes sense since all the remaining retiring of orphaned packages discussion happened there.

I think it is reasonable to remove committers. On the one hand, existing committers are obviously not interested in the package. And if the package is ever unretired, we expect to put in a new set of committers. On the other hand, removing existing committers — and in particular groups — helps ensure that no accidental modifications will be pushed.

This would make sense when the last branch is retired/becomes EOL.

However, one thing I realized is that previously, it was possible to retire the package just for specific branches and to manage ACLs per branch. It is not possible now AFAIK. That might be the reason, why the group is still listed as maintainer of the package. But will it be ever corrected? I don't think so, but I might be mistaken.

It is possible to retire individual branches but not possible to have individual branch ownership. I.e. if the package is retired for Rawhide, the commiters can only commit to the remaining branches (at least I hope this is how pagure implements this) - at least building will not be possible for the retired branches.

Assigned to @humaton

We now remove things from retired packages.

Can you see if it looks like you expect now and close this?

Give that I have asked to unretire coffee-script package recently [1] and there are still other member except myself, I don't think that my concerns were addressed (unless it happened in the past 3 days, then I don't have any test case at my hand).

Looking at js-jquery1, isn't it all due to EPEL?

It looks like we only run this job once per month on the 1st:
cronjob.batch/playtime-clean-retired-packages 0 8 1 * * False 0 21d 305d

@pingou could we run this more often? say daily?

Looking at js-jquery1, isn't it all due to EPEL?

I don't see that package as being retired?

It looks like we only run this job once per month on the 1st:
cronjob.batch/playtime-clean-retired-packages 0 8 1 * * False 0 21d 305d

@pingou could we run this more often? say daily?

It takes a little while to run and it's meant to clean-up packages that have not been retired properly, it shouldn't be the default mechanism.

I wouldn't run it more often than twice a month.

I don't see that package as being retired?

https://src.fedoraproject.org/rpms/js-jquery1/c/06238b04753f5291b92c10bd5061b73b67652d42?branch=rawhide

ok, so indeed that was 10 months ago...

@pingou any idea why the clean didn't clean it?

ok, so indeed that was 10 months ago...

@pingou any idea why the clean didn't clean it?

@zlopez and I just fixed an issue in the script which prevented it from running,
as far as I could see at least the last two months.
Did that change anything?

ok, I just went to https://src.fedoraproject.org/rpms/js-jquery1/ to check it.

Actually, it is not fully retired:
https://src.fedoraproject.org/rpms/js-jquery1/branches?branchname=rawhide
It seems to be still active in EPEL7, that's why it hasn't been processed by the
script.

The script is in place, closing.