Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[William Hubbs]

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.
> >
>
> 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