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
signature.asc
Description: Digital signature
