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

[William Hubbs <williamh@gentoo.org>]

[-- 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 --]