* Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
@ 2016-08-05 14:28 99% ` William Hubbs
0 siblings, 0 replies; 1+ results
From: William Hubbs @ 2016-08-05 14:28 UTC (permalink / raw
To: gentoo-project
[-- 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 --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2016-08-04 14:15 [gentoo-project] Call for agenda items - Council meeting 2016-08-14 Kristian Fiskerstrand
2016-08-04 16:24 ` William Hubbs
2016-08-04 20:12 ` Andrew Savchenko
2016-08-04 22:22 ` William Hubbs
2016-08-04 23:25 ` Rich Freeman
2016-08-05 2:26 ` William Hubbs
2016-08-05 10:57 ` Rich Freeman
2016-08-05 14:28 99% ` William Hubbs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox