RFC: Simply the retirement procedure - trigger on dead.package

[Al Dunsmuir]

On Wednesday, November 27, 2013, 2:30:23 PM, Ralph Bean wrote:
> On Wed, Nov 27, 2013 at 07:46:28PM +0100, Till Maas wrote:
>> On Wed, Nov 27, 2013 at 12:35:13PM -0600, Bruno Wolff III wrote:
>> > On Wed, Nov 27, 2013 at 19:21:53 +0100,
>> >   Till Maas <opensource at till.name> wrote:
>> > >
>> > >What are your opinions about this? I already checked with Dennis
>> > >Gilmore, he is ok with this.
>> > 
>> > Is there a fail against doing this in released versions? (Unless
>> > there is a legal reason to do the retirement, we wouldn't want to do
>> > that for a package in a release.)
>> 
>> It will be done only for Rawhide and Branched (until the Final Change
>> Deadline) and maybe EPEL if desired. Wether or not to e.g. retire
>> packages for other releases without blocking them in Koji needs to be
>> decided.
>> 
>> Regards
>> Till

> Sounds like a good idea to me.  Also seems like it is important enough
> to run inside the infrastructure environment so that it can be
> monitored.

> The #fedora-apps team has been working on pkgdb2 which the authors
> hope to deploy shortly after the F20 release.  Restricting retirement
> rights to the automated process shouldn't be a problem.

What  about  un-retirement? It is critical that administrators be able
to handle this side of the packaging process, even after a release has
been branched.

Ideally,  if  that  could  be just as fast. I would suggest triggering
this  on  the _removal_ of the dead.package file in git, which perhaps
would require proven-packager authority vs simply package ownership.

This  would  make  it  a lightweigth process to handle resurrection of
oprhaned and retired package or in case an error occurs. This would be
especially  useful  if  a  large  number of packages were accidentally
retired.

Al