From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: williamh@gentoo.org
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 10:54:15 +0100 [thread overview]
Message-ID: <20140115105415.5df3cdac@pomiot.lan> (raw)
In-Reply-To: <20140114213719.GA2684@laptop.home>
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]
Dnia 2014-01-14, o godz. 15:37:19
William Hubbs <williamh@gentoo.org> napisał(a):
> I want comments wrt two ideas:
>
> 1. I think maintainers should be able to stabilize their packages on arch's
> they have access to. I think this is allowed by some arch teams, but I
> think it would be good to formalize it.
I think we'd use more feedback from the 'other' arch teams before
agreeing on this. Some arches may have a pretty tricky issues that
could affect stabilization but which average developer may be not aware
of. Maybe it'd be good if each arch team had a wiki page explaining
the testing process for their arch.
We should also make it clear that the developer is supposed to test
the package on a pure stable system to avoid misunderstandings.
> 2. I would like to see the policy below applied to all arch's [2].
>
> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
Honestly, this sounds like a very bad idea to me. Even on the minor
architectures.
TLDR: users will end up running unsupported mixed-arch systems
and stabilizing the package again sometime wouldn't make much sense.
Dropping the stable keyword on a package means that user either:
1) has to remove the package and either find an alternative or lose
particular features completely. And unlike with regular package.mask,
he won't get any tips from us. In fact, this policy makes it possible
to kill, say, the last graphical word processor on the arch.
2) has to add package.accept_keywords entry for the package. Which
means turning a pure stable system into an unsupported mixed-keyword
system.
Considering portage behavior, I think that 2) is much more likely. Now,
the keyword may be added per-version or per-package. If it's added
per-version, user simply ends up sticking to another single version
until he thinks of upgrading the package manually.
If it's added per-package, the keyword usually persists on the user's
system. When we bring the stable keywords to the package again, user
would have to notice that and remove his override. How likely is that
going to happen?
So, in the end once we remove stable keyword from a package, most users
add ~arch keyword and future stable keyword on the package becomes
meaningless.
I'd rather go for removing stable keywords from all packages. This
would at least make turning the architecture back stable easy for users.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]
next prev parent reply other threads:[~2014-01-15 9:54 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 21:37 [gentoo-dev] rfc: revisiting our stabilization policy William Hubbs
2014-01-14 21:57 ` Michael Orlitzky
2014-01-14 22:33 ` William Hubbs
2014-01-14 22:43 ` Michael Orlitzky
2014-01-14 23:11 ` William Hubbs
2014-01-14 23:22 ` Jeff Horelick
2014-01-15 0:28 ` Tom Wijsman
2014-01-15 23:59 ` [gentoo-dev] " Duncan
2014-01-16 0:23 ` Tom Wijsman
2014-01-15 0:47 ` [gentoo-dev] " Michael Orlitzky
2014-01-15 1:08 ` Tom Wijsman
2014-01-15 1:11 ` Michael Orlitzky
2014-01-15 1:23 ` Tom Wijsman
2014-01-15 1:36 ` Michael Orlitzky
2014-01-15 2:09 ` William Hubbs
2014-01-15 2:21 ` Michael Orlitzky
2014-01-15 2:34 ` Tom Wijsman
2014-01-15 2:40 ` Michael Orlitzky
2014-01-15 3:26 ` Tom Wijsman
2014-01-15 2:46 ` William Hubbs
2014-01-16 7:28 ` Christopher Head
2014-01-16 22:44 ` Tom Wijsman
2014-01-19 22:31 ` Christopher Head
2014-01-20 0:47 ` Tom Wijsman
2014-01-23 18:12 ` [gentoo-dev] " Steven J. Long
2014-01-23 19:13 ` Tom Wijsman
2014-01-23 20:55 ` Steev Klimaszewski
2014-01-23 22:38 ` Tom Wijsman
2014-01-23 22:42 ` Peter Stuge
2014-01-23 23:50 ` Tom Wijsman
2014-01-24 0:04 ` Steev Klimaszewski
2014-01-24 3:04 ` Tom Wijsman
2014-01-24 3:52 ` Steev Klimaszewski
2014-01-24 17:26 ` Tom Wijsman
2014-01-24 18:10 ` Steev Klimaszewski
2014-01-24 19:29 ` Tom Wijsman
2014-01-24 20:29 ` Steev Klimaszewski
2014-01-24 21:55 ` Tom Wijsman
2014-01-24 10:46 ` Steven J. Long
2014-01-24 18:26 ` Tom Wijsman
2014-01-25 4:02 ` Duncan
2014-01-26 0:50 ` Peter Stuge
2014-01-26 0:59 ` Rich Freeman
2014-01-26 4:53 ` Peter Stuge
2014-01-26 11:41 ` Rich Freeman
2014-01-26 18:56 ` Peter Stuge
2014-01-26 21:35 ` Rich Freeman
2014-01-27 7:41 ` Steev Klimaszewski
2014-01-27 14:52 ` Rich Freeman
2014-01-28 2:45 ` Steev Klimaszewski
2014-01-26 22:56 ` Duncan
2014-01-26 23:40 ` Duncan
2014-01-28 12:37 ` Steven J. Long
2014-01-28 12:52 ` Alan McKinnon
2014-01-28 13:18 ` Tom Wijsman
2014-01-28 13:11 ` Tom Wijsman
2014-01-29 3:15 ` Duncan
2014-01-29 6:34 ` Steev Klimaszewski
2014-01-15 2:42 ` [gentoo-dev] " Tom Wijsman
2014-01-15 11:33 ` Sergey Popov
2014-01-15 16:57 ` Tom Wijsman
2014-01-15 17:20 ` Matthew Thode
2014-01-15 2:26 ` Tom Wijsman
2014-01-15 11:28 ` Sergey Popov
2014-01-15 0:13 ` Tom Wijsman
2014-01-15 0:50 ` Michael Orlitzky
2014-01-15 1:13 ` Tom Wijsman
2014-01-15 23:13 ` [gentoo-dev] " Duncan
2014-01-15 0:04 ` [gentoo-dev] " Tom Wijsman
2014-01-14 23:49 ` Tom Wijsman
2014-01-15 0:06 ` Andreas K. Huettel
2014-01-15 0:17 ` Anthony G. Basile
2014-01-15 0:43 ` Tom Wijsman
2014-01-15 0:38 ` Tom Wijsman
2014-01-15 0:46 ` William Hubbs
2014-01-15 1:26 ` Tom Wijsman
2014-01-15 11:40 ` Sergey Popov
2014-01-15 17:04 ` Tom Wijsman
2014-01-16 6:20 ` Sergey Popov
2014-01-16 15:54 ` Peter Stuge
2014-01-16 17:56 ` Rich Freeman
2014-01-16 18:04 ` Alan McKinnon
2014-01-16 18:26 ` Peter Stuge
2014-01-16 20:18 ` Alan McKinnon
2014-01-16 20:40 ` Peter Stuge
2014-01-16 18:11 ` Peter Stuge
2014-01-16 18:42 ` Rich Freeman
2014-01-16 19:29 ` William Hubbs
2014-01-16 19:59 ` Peter Stuge
2014-01-16 22:49 ` Tom Wijsman
2014-01-15 3:48 ` grozin
2014-01-15 4:49 ` William Hubbs
2014-01-15 5:07 ` Robin H. Johnson
2014-01-15 8:03 ` Dirkjan Ochtman
2014-01-15 8:18 ` Hans de Graaff
2014-01-15 16:11 ` [gentoo-dev] " Michael Palimaka
2014-01-15 9:54 ` Michał Górny [this message]
2014-01-15 12:51 ` [gentoo-dev] " Rich Freeman
2014-01-15 21:41 ` [gentoo-dev] " Duncan
2014-01-15 11:24 ` [gentoo-dev] " Sergey Popov
2014-01-15 11:30 ` Sergey Popov
2014-01-15 15:30 ` William Hubbs
2014-01-16 6:17 ` Sergey Popov
2014-01-17 6:06 ` grozin
2014-01-17 7:02 ` grozin
2014-01-17 7:58 ` Matt Turner
2014-01-17 15:02 ` Rich Freeman
2014-01-17 15:02 ` Michał Górny
2014-01-18 1:35 ` William Hubbs
2014-01-17 15:31 ` Ulrich Mueller
2014-01-17 16:47 ` Tom Wijsman
2014-01-17 17:08 ` grozin
2014-01-18 0:34 ` Manuel Rüger
2014-01-17 18:28 ` Ciaran McCreesh
2014-01-17 23:56 ` Tom Wijsman
2014-01-18 12:59 ` [gentoo-dev] arch="any" (Re: rfc: revisiting our stabilization policy) Steven J. Long
2014-01-17 17:07 ` noarch packages, was Re: [gentoo-dev] rfc: revisiting our stabilization policy grozin
2014-01-19 8:36 ` Mike Frysinger
2014-01-19 9:28 ` Add a KEYWORD representing any arch (was: Re: [gentoo-dev] rfc: revisiting our stabilization policy) Pacho Ramos
2014-01-19 9:46 ` [gentoo-dev] Re: Add a KEYWORD representing any arch Ulrich Mueller
2014-01-19 10:15 ` Pacho Ramos
2014-01-20 19:25 ` Steev Klimaszewski
2014-01-22 15:46 ` Jeroen Roovers
2014-01-19 9:48 ` Add a KEYWORD representing any arch (was: Re: [gentoo-dev] rfc: revisiting our stabilization policy) Mike Frysinger
2014-01-17 21:04 ` [gentoo-dev] rfc: revisiting our stabilization policy Maciej Mrozowski
2014-01-15 18:33 ` Thomas Sachau
2014-01-15 19:07 ` William Hubbs
2014-01-16 0:58 ` Steev Klimaszewski
2014-01-16 2:32 ` Robin H. Johnson
2014-01-16 5:47 ` Steev Klimaszewski
2014-01-19 11:06 ` Thomas Sachau
2014-01-16 6:27 ` Sergey Popov
2014-01-16 7:15 ` [gentoo-dev] " Michael Palimaka
2014-01-15 19:13 ` [gentoo-dev] " Ruud Koolen
2014-01-15 21:54 ` [gentoo-dev] " Martin Vaeth
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=20140115105415.5df3cdac@pomiot.lan \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=williamh@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