#6024 Clear old ACLs when unretiring a package
Closed: Fixed None Opened 9 years ago by hannes.

Hi all,

at the moment, when a new package was re-reviewed and the git request was processed the original maintainer, who perhaps initially imported the package has still commit access to various branches, most importantly to the devel branch.
In this particular case the original maintainer stopped working on the package in 2010, at least that was when he last initiated a build on koji. [1]
I then took it over until it was retired by me, because upstream was dead and it wasn't really necessary any more. It was then again picked up by a different upstream, who contacted me and asked me to introduce it to fedora again. I did so and filed a review ticket and did all the necessary steps. [2]
And then after it was approved and the git process was done, I noticed in pkgdb, that the original maintainer was still listed there. [3]
I mean of course this is not a big problem, but if he really would be interested to me it would seem more natural, that he then requests co-maintainership and don't gets it automatically.

-johannes
[1] http://koji.fedoraproject.org/koji/packageinfo?packageID=3984
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1153302
[3] https://admin.fedoraproject.org/pkgdb/package/tilda/


Do I understand correclty that you propose to clear the ACLs when a package is unretired and only use the specified ACLs?

Do I understand correclty that you propose to clear the ACLs when a package is unretired and only use the specified ACLs?

Well, yes that's basically what I mean. Perhaps it might be optional to restore the existing ACLs, but to clear them per default. To me it seems much more logical, but I could be wrong of course.

Well, yes that's basically what I mean. Perhaps it might be optional to restore the existing ACLs, but to clear them per default. To me it seems much more logical, but I could be wrong of course.

Note that we are not dropping the commit and watchcommits ACL when an user orphans a package: https://github.com/fedora-infra/pkgdb2/pull/90

Note that we are not dropping the commit and watchcommits ACL when an user orphans a package: https://github.com/fedora-infra/pkgdb2/pull/90

This has been discussed at the rel-eng meeting today.

We decided to go the route of: when a package is orphaned, the person orphaning it looses commit and watchcommits ACLs on it (as it is already doing now) and when a package is retired, everyone looses all ACLs on it (which is new).

This behavior has been implemented in: https://github.com/fedora-infra/pkgdb2/pull/107

This has been discussed at the rel-eng meeting today.

We decided to go the route of: when a package is orphaned, the person orphaning it looses commit and watchcommits ACLs on it (as it is already doing now) and when a package is retired, everyone looses all ACLs on it (which is new).

This behavior has been implemented in: https://github.com/fedora-infra/pkgdb2/pull/107

Replying to [comment:6 pingou]:

This has been discussed at the rel-eng meeting today.

We decided to go the route of: when a package is orphaned, the person orphaning it looses commit and watchcommits ACLs on it (as it is already doing now) and when a package is retired, everyone looses all ACLs on it (which is new).

I was not able to make it to the meeting, but I think removing the ACLs when a package is unretired would be better. This allows to easier figure out who maintained a retired package previously so one can easier ask the previous maintainers about any issues if it is planned to unretire the package again.

Replying to [comment:6 pingou]:

This has been discussed at the rel-eng meeting today.

We decided to go the route of: when a package is orphaned, the person orphaning it looses commit and watchcommits ACLs on it (as it is already doing now) and when a package is retired, everyone looses all ACLs on it (which is new).

I was not able to make it to the meeting, but I think removing the ACLs when a package is unretired would be better. This allows to easier figure out who maintained a retired package previously so one can easier ask the previous maintainers about any issues if it is planned to unretire the package again.

Replying to [comment:7 till]:

Replying to [comment:6 pingou]:

This has been discussed at the rel-eng meeting today.

We decided to go the route of: when a package is orphaned, the person orphaning it looses commit and watchcommits ACLs on it (as it is already doing now) and when a package is retired, everyone looses all ACLs on it (which is new).

I was not able to make it to the meeting, but I think removing the ACLs when a package is unretired would be better. This allows to easier figure out who maintained a retired package previously so one can easier ask the previous maintainers about any issues if it is planned to unretire the package again.

The ACLs are still present, when I said drop I meant marked as 'Obsolete' so you would still see the previous packager of the application, they would just have no valid ACLs on it.

Replying to [comment:7 till]:

Replying to [comment:6 pingou]:

This has been discussed at the rel-eng meeting today.

We decided to go the route of: when a package is orphaned, the person orphaning it looses commit and watchcommits ACLs on it (as it is already doing now) and when a package is retired, everyone looses all ACLs on it (which is new).

I was not able to make it to the meeting, but I think removing the ACLs when a package is unretired would be better. This allows to easier figure out who maintained a retired package previously so one can easier ask the previous maintainers about any issues if it is planned to unretire the package again.

The ACLs are still present, when I said drop I meant marked as 'Obsolete' so you would still see the previous packager of the application, they would just have no valid ACLs on it.

Thanks for the quick fix!

Thanks for the quick fix!

This should be all fixed now, right?

Please reopen if there's further to do.

This should be all fixed now, right?

Please reopen if there's further to do.

Metadata Update from @hannes:
- Issue assigned to pingou
- Issue set to the milestone: Fedora 20 Final
- Issue tagged with: meeting

7 years ago

Login to comment on this ticket.

Metadata