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

[William Hubbs]

On Thu, Aug 04, 2016 at 11:12:24PM +0300, Andrew Savchenko wrote:
> Hi all,
>
> On Thu, 4 Aug 2016 11:24:43 -0500 William Hubbs wrote:
> > I feel that our stable tree is so far behind on all
> > architectures that we are doing our stable users a disservice, so I
> > would like to open up a discussion here, and maybe some policy changes
> > at the next meeting.
>
> Thank you for caring about this issue. I had similar thoughts
> myself, but was too slow on writing e-mail :) IMO stable tree has
> three problems:
> 1) too old packages
> 2) too few packages
> 3) stabilization often takes too long, such stable packages are
> broken or buggy, while their unstable versions are fixed and work
> fine. (It is not possible to fix all bugs without version or
> revision bump, thus stabilization is needed to fix many bugs.)
 
 "too few packages" doesn't really affect things much, I'm more
 concerned about 1 and 3. If packages are not stable in the first place,
 that is because the maintainer hasn't requested stabilization, and that
 is a separate issue.

> > Ultimately, I think we need some form of automated stabilization, e.g.
> > if a package version sits in ~ for 30 days and there are no blockers at
> > that point, the new version should go automatically to stable on all
> > architectures where there is a previous stable version.
>
> Automation should be possible only after rigorous testing. If this
> will be implemented, than this may be done (as Brian pointed out in
> another mail in this thread, there is an ongoing effort on this
> matter as GSoC project, which is great). But I'd like to emphasize
> that automated stabilization without:
> a) build testing;
> b) run-time testing;
> c) fixing all serious open bugs affecting package being stabilized.
>
> Automation tests will definitely help here, but I'm not sure that
> packages can be fully tested without human intervention:
> - how to automatically test GUI app run-time?
> - how to determine which open bugs from bugzilla are serious enough
> to block stabilization, and which bugs shouldn't block the process?
>
> IMO automation can help with build tests, maybe limited run-time
> testing, but no more.

This is why there is a period for a package to be in ~ before it goes to
stable. All of this rigorous testing you are talking about should be
done by people who are running the ~ version of the package and bugs
should be reported. Automated stabilization just refers to checking to
see if there any bugs against the latest ~ version of a package that
should block stabilization, and if there are not, maybe doing a build
test then stabilizing.

>
> > The first issue is maintainers not filing stable requests for new
> > versions of packages in a timely manor. I'm not sure how to get around
> > this, but I feel that once a version of a package is stable, we are
> > doing a disservice to our stable users by not keeping stable as current
> > as possible.  I am as bad as anyone; it is easy to forget to file
> > stable requests until someone pings me or files the request
> > themselves.
>
> We have another problem: arch teams often can't keep up with
> stabilization requests, they are hanging for months, I even have
> several bugs open for more than half a year. Storming arch teams
> with stabilization requests will make things even worse.
 
I'm not proposing storming the arch teams with stable requests, see
below.

> > I have heard other maintainers say specifically that they do not file
> > stable requests unless a user asks them to, but Again, I do not feel
> > comfortable with this arrangement if there is an old version of the
> > package in stable. Users shouldn't have to ask for newer versions to be
> > stabilized; this should be driven by the maintainers.
>
> I usually stabilize versions when they are too old or I have a user
> request. The idea is not to stabilize as often as unstable version
> is updated, since arch teams are unable to keep up even with
> request rate they have now.
 
 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.

> > The second issue is slow arch teams. Again, by not moving packages from
> > ~ to stable, we are doing a disservice to our stable users.
>
> And here comes my idea. We need an approved policy of how to remove
> packages from stable (I'll name this procedure as "dekeywording"
> below). Right now we only have a mention in the devmanual, that arch
> teams must be informed via a bug [1] on dekeywording. But we have no
> determined time frame, nor policy about reverse dependencies.
 
 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.

My proposal doesn't apply to all packages that are in ~, only to
packages that have a version in stable.

I'm suggesting that once a package has a version in stable, newer
versions need to be stabilized in a timely manor, e.g. 30 days at most
after they enter the tree once all of their dependencies are stable.

Here are the ways I would do this:

1. First, this assumes that all reverse dependencies of the package in
consideration are stable. It also assumes that the package in
consideration has an older version in stable.

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.

2. For other packages , once the testing period is passed, a stable request
will be filed for the new version. Once
another 30 days has passed without a response from the arch teams, the
maintainer would be allowed to stabilize the new version on all arches
that have an older stable version.

This would satisfy the expectation that a package version in the stable
tree cannot be removed until there is a newer stable version.

William