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@xxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
