* Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
@ 2016-08-04 23:25 99% ` Rich Freeman
0 siblings, 0 replies; 1+ results
From: Rich Freeman @ 2016-08-04 23:25 UTC (permalink / raw
To: gentoo-project
On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Thu, Aug 04, 2016 at 11:12:24PM +0300, Andrew Savchenko wrote:
>>
>> 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.
I'm less concerned with old (within reason) and few. I think the
primary criteria has to always be that the packages are reliable. If
somebody wants to make the tradeoff less reliability and fresher
packages they can just install testing.
>
> 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.
I'm not suggesting anything rigorous. However, it would be a bit
embarrassing to stabilize a package and find that it doesn't even
build, or which has some glaring issue. Build testing at least could
be automated, but I'm not sure if we need more than that. I'm not
entirely opposed to loosening things up on a trial basis and seeing
how it goes. However, if we're going to do that I wouldn't go nuts
with automation in case we decide to back off.
>
> 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.
However, this shouldn't be done lightly. This isn't for that package
that is 60 days old. And it really should be the last resort when the
maintainer can't just stabilize it on their own (it is a bigger issue
for minor archs where hardware is less available and arch teams don't
have time to touch it).
>
> 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.
--
Rich
^ 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 99% ` Rich Freeman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox