Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14

[William Hubbs <williamh@gentoo.org>]

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

On Fri, Aug 05, 2016 at 06:57:59AM -0400, Rich Freeman wrote:
> On Thu, Aug 4, 2016 at 10:26 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote:
> >>
> >> I'm mostly fine with that, but I'd add just a requirement that
> >> somebody does a quick sanity check on an otherwise-stable system.  The
> >> 30 days of testing is really only testing against dependencies that
> >> are in ~arch.  Granted, that will become less of a concern if all
> >> those dependencies are also making their way to stable.
> >
> >  Repoman will complain loudly if you try to stabilize something that
> >  doesn't have all of its reverse dependencies stabilized, so I think we
> >  are safe as long as people listen to repoman. I'm not advocating
> >  stabilizing things with ~ reverse dependencies, just trying to find a
> >  way to move stabilization along better than it has been moving.
> >
> 
> This only helps if the sanity check is correct.  If a package has a
> dependency on foo/bar, but it should have >=foo/bar-2, and ~arch is at
> -2 and stable is at -1, then repoman will happily let you stabilize
> your package even though it will break.  Spending 30 days in testing
> might or might not spot the issue, it depends on whether users running
> mixed keywords test it.  Since most testing users aren't running mixed
> keywords they may not spot that the package breaks with bar-1.
 
 I think if you are doing this sort of testing you need to run a
 mostly stable system. If you are running full ~, you definitely would
 miss issues like this.  I, for one, do not run full ~.

I would actually recommend for devs that they run stable on everything
except packages they maintain. If you do that, you catch issues like
this.

 *snip*

> Are the older packages actually hurting anybody?  For the most common
> arch (amd64) maintainers can just stabilize their own packages, so old
> stable packages shouldn't be hurting maintainers (or if they are it is
> self-inflicted...).

I don't have the numbers in front of me, but from what I hear recently
amd64 has become one of the more lagging architectures. I don't know if
it is because most of our devs are running full ~ and are not set up to
test against stable or if, like some I've talked to, it is just that
they prefer a second set of eyes to go over a  package before it is
stabilized.

Besides our maintainers keeping old packages around, we are doing a
disservice to our stable users by offering them old software instead of
keeping them as current as possible.

William


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