On Mon, Aug 15, 2016 at 1:31 PM, William Hubbs <willi...@gentoo.org> wrote: > 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. >
I'm fine with maintainers de-keywording packages on their own initiative. However, if a maintainer hasn't even built a package on an arch, they shouldn't be stabilizing it on that arch. That would make the concept of stable meaningless. If it is just ~arch plus a time delay, then we should just get rid of the stable keywords and instead have portage just filter packages by the date they were committed to ~arch. I'd rather see maintainers just yank the last stable package and break the depgraph and let the arch teams deal with the cleanup than have them mark stuff stable without any testing at all. Or build a script that does the keyword cleanup for them. De-keywording late stable requests is a solution that is self-correcting. As packages are reduced from the stable set then there are fewer stable requests and the arch team is better able to focus on the ones they deem important. Throwing more packages in stable that aren't actually stable just makes that problem worse, and destroys whatever value the stable keyword had on the arch. For small arch teams they really should be focusing their time on core packages. -- Rich
