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

[Till Maas]

Hi,

while cleaning up retired packages (which I did not yet finish), I came
up with an idea to simplify the retirement procedure to avoid
inconsistencies. With the help of fedmsg I would like to make it enough
wrt to koji and pkgdb to add a dead.package file to dist git to
retire a package. When this happens, an automated process will retire
the package in pkgdb and block the package in koji. This will make
it impossible to only dead.package or only retire a package in pkgdb.

To avoid problems with lost messages from fedmsg, a regular cleanup job
can download a git checkout and check for any missed dead.package files.

What are your opinions about this? I already checked with Dennis
Gilmore, he is ok with this.

My plan is to  first setup a service that triggers the retirement in
pkgdb and when this seems to work ask Infrastructure do disable retiring
packages for regular users in pkgdb.

Regards
Till

[Bruno Wolff III]

On Wed, Nov 27, 2013 at 19:21:53 +0100,
   Till Maas <opensource(a)till.name&gt; 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.)

[Till Maas]

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(a)till.name&gt; 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

[Ralph Bean]

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(a)till.name&gt; 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.

[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(a)till.name&gt; 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

[Till Maas]

On Wed, Nov 27, 2013 at 04:01:07PM -0500, Al Dunsmuir wrote:

>  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. 
This is out-of-scope for my proposal, except that no packages should be
retired automatically after they were unretired.

>  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. 
Unretirement requires manual inspection, because a re-review might be
required. Also it happens less often than retirement and it is easily
possible to retire a large amount of packages by administrative users if
required. Therefore I do not see the need for improvements.

Regards
Till

[Toshio Kuratomi]

On Wed, Nov 27, 2013 at 07:21:53PM +0100, Till Maas wrote:
>  Hi,
>  
>  while cleaning up retired packages (which I did not yet finish), I came
>  up with an idea to simplify the retirement procedure to avoid
>  inconsistencies. With the help of fedmsg I would like to make it enough
>  wrt to koji and pkgdb to add a dead.package file to dist git to
>  retire a package. When this happens, an automated process will retire
>  the package in pkgdb and block the package in koji. This will make
>  it impossible to only dead.package or only retire a package in pkgdb.
>  
>  To avoid problems with lost messages from fedmsg, a regular cleanup job
>  can download a git checkout and check for any missed dead.package files.
>  
>  What are your opinions about this? I already checked with Dennis
>  Gilmore, he is ok with this.
>  
>  My plan is to  first setup a service that triggers the retirement in
>  pkgdb and when this seems to work ask Infrastructure do disable retiring
>  packages for regular users in pkgdb.
>   
Works for me -- depending on when this goes live, we might be making the
retirement change in pkgdb2 instead of pkgdb1.  (We're trying to get pkgdb2
live in January).  (And by we I mean pingou who is doing all of the hard
work on pkgdb2 ;-)

-Toshio