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

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]