public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* 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