* Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
@ 2016-08-05 2:26 99% ` William Hubbs
0 siblings, 0 replies; 1+ results
From: William Hubbs @ 2016-08-05 2:26 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]
On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote:
> On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs <williamh@gentoo.org> wrote:
*snip*
> >
> > My proposal is saying that if you have a version of a package in ~,
> > testing is being done, and at the end of the testing period (30 days at
> > most), that new version in ~ should move to stable if there are no
> > blockers. It would be up to you, the maintainer, or any users running
> > the ~ version, to test and file bugs that block stabilization. These
> > bugs could be detected automatically.
> >
>
> 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.
*snip*
> >
> > We basically do. I don't have a link in front of me, but the council
> > did make a decision allowing the removal of packages from the stable
> > tree. It hasn't played out well though, because stable users expect
> > that once a package is in the stable tree it will stay there until a
> > newer version comes to the stable tree.
>
> I'd have to look up the exact decision, but it was basically left to
> maintainer discretion after some time lag. I think it is a useful
> safety valve. If the maintainer feels that the stable version is
> de-facto unmaintained and is causing problems, then we're not doing
> stable users any favors by just leaving it on their systems. Just go
> ahead and drop it and stable users can stick it in an overlay if they
> know what they're doing, but they won't just live with some unknown
> issue.
If we can get the newer version stabilized, we can then remove the
older version without breaking stable, so this then becomes a
non-issue.
Also, getting the newer version stabilized is a more favorable approach
because you don't have to deal with breaking the depgraph, or in the
case of a package that is in the stages, if you remove the stable
version, you can break the stages for that arch.
*snip*
> >
> > 2. if the package is all data files, or if it is written in an
> > interpreted language e.g. python, perl, etc., Once the testing period
> > has passed, the maintainer will be allowed to stabilize it on all arches
> > that have a stable version without a stable request.
>
> I believe there is already widespread agreement on this point. We've
> talked about mechanisms to designate these packages but if we just
> want to go with maintainer discretion we might be fine.
Well, let me back up a bit on this one. We have the allarches keyword
which can be added to a stable request to let the first arch team know
to stabilize on all listed arches.
Maybe we should forget option 2, and just say that if a package version is in ~
with a stable request opened for more than 30 days with all of its
reverse dependencies stable the maintainer can stabilize that version of
the package on all arches that have a stable version.
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 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