On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote: > 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. ok, this makes sense.
> 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, This was my original thinking about this issue. It turned out to be more controversial than I originally thought -- folks told me that stable tree users expect stability above all, so breaking the depgraph is unacceptable, so I'm just trying to find something that is more palletable. I have a few bugs right now where I haven't done this because I know it is going to require "repoman commit --force" to work, and set of our ci alarms etc. Should I not care about that and just let the arch teams clean it up? William
signature.asc
Description: Digital signature
