I want to elaborate a bit more on this.

On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote:
> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> > > On 08/15/2016 04:19 PM, William Hubbs wrote:
> > >> I'm very much for this as well. Themaintainer should be able to
> > >> stabilize on all arches after the timeout. That would solve the primary
> > >> concern I have about the stable tree lagging.
> > > 
> > > It depends on the context, if it is not security related or fixing a
> > > known bug, it can cause regression for stable users without much gain.

The maintainer of the package is going to have the most intimate knowledge about
these types of issues in the package, so I would rather have the maintainer
make these types of decisions instead of restricting him with some global policy.

> > 
> > Elaborating on this, if we're talking about maintainer stabilizing it
> > after testing it properly there is no issue, but there shouldn't be a
> > policy to auto-mark stable
> 
> As a maintainer, if there is an old version of a package in stable for
> some arch and I have a stable request open for a newer version and the
> arch team doesn't respond to the stable request within a reasonable
> amount of time, I want to do one of two things:
> 
> - destabilize all versions of the package on this arch. That would allow
>   me to move on and take the worry about stabilizing this package off of
>   the arch team in the future.  or
> - if there are no blockers, stabilize the new version and deal with the
> fallout myself if there is any.
> 
> If there is not an old version of the package marked stable, closing the
> stablereq and moving on is probably what I would do after a certain
> amount of time.
> 
> Maintaining a viable stable tree is a team effort between the
> maintainers and the arch teams. If the arch teams are so overwhelmed
> with stable requests that they can't keep things current, the
> maintainers should be able to stabilize the newer versions and deal with
> the fallout as a last resort, or decide that they don't want their
> packages stable on those arches until the arch teams can keep up.
> 
> William
>