From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
Date: Thu, 4 Aug 2016 19:25:52 -0400 [thread overview]
Message-ID: <CAGfcS_=TwWJxjh+PUninJssMAVakUaRA5WGZ5cbSwz+XR0qQyA@mail.gmail.com> (raw)
In-Reply-To: <20160804222234.GA8357@whubbs1.gaikai.biz>
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
next prev parent reply other threads:[~2016-08-04 23:25 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
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 17:08 ` Dirkjan Ochtman
2016-08-04 17:09 ` Brian Dolbec
2016-08-04 18:31 ` William Hubbs
2016-08-04 20:12 ` Andrew Savchenko
2016-08-04 22:22 ` William Hubbs
2016-08-04 23:25 ` Rich Freeman [this message]
2016-08-05 2:26 ` William Hubbs
2016-08-05 10:57 ` Rich Freeman
2016-08-05 14:28 ` William Hubbs
2016-08-05 14:36 ` Rich Freeman
2016-08-05 15:36 ` William Hubbs
2016-08-08 12:35 ` Marek Szuba
2016-08-08 19:51 ` Pacho Ramos
2016-08-09 2:07 ` Jack Morgan
2016-08-09 5:32 ` Kent Fredric
2016-08-09 5:59 ` Rich Freeman
2016-08-09 10:05 ` Kent Fredric
2016-08-09 14:41 ` Brian Dolbec
2016-08-09 15:12 ` Kent Fredric
2016-08-09 16:15 ` Brian Dolbec
2016-08-09 17:09 ` Kent Fredric
2016-08-09 17:12 ` Brian Evans
2016-08-09 17:18 ` Chí-Thanh Christopher Nguyễn
2016-08-09 17:22 ` Ciaran McCreesh
2016-08-09 20:08 ` Rich Freeman
2016-08-09 20:14 ` Kristian Fiskerstrand
2016-08-09 20:20 ` Kristian Fiskerstrand
2016-08-10 1:15 ` Pallav Agarwal
2016-08-10 1:28 ` Brian Dolbec
2016-08-05 17:32 ` Kristian Fiskerstrand
2016-08-05 17:29 ` Kristian Fiskerstrand
2016-08-04 21:30 ` Daniel Campbell
2016-08-05 16:11 ` Michael Orlitzky
2016-08-05 16:22 ` [gentoo-project] " Michael Palimaka
2016-08-05 17:06 ` Michael Orlitzky
2016-08-05 17:11 ` Chí-Thanh Christopher Nguyễn
2016-08-05 17:38 ` Michael Orlitzky
2016-08-05 17:19 ` Michał Górny
2016-08-05 17:21 ` Michael Orlitzky
2016-08-05 17:31 ` [gentoo-project] " Kristian Fiskerstrand
2016-08-05 18:42 ` William Hubbs
2016-08-05 18:45 ` Kristian Fiskerstrand
2016-08-05 18:55 ` NP-Hardass
2016-08-05 19:03 ` Kristian Fiskerstrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGfcS_=TwWJxjh+PUninJssMAVakUaRA5WGZ5cbSwz+XR0qQyA@mail.gmail.com' \
--to=rich0@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox