* [gentoo-dev] Re: rfc: revisiting our stabilization policy
@ 2014-01-15 21:41 99% ` Duncan
0 siblings, 0 replies; 1+ results
From: Duncan @ 2014-01-15 21:41 UTC (permalink / raw
To: gentoo-dev
Rich Freeman posted on Wed, 15 Jan 2014 07:51:49 -0500 as excerpted:
> Given constrained manpower the options basically are some variation on:
> 1. Status quo - for some packages stable gets REALLY old, and likely has
> problems that maintainers ignore. You can't force somebody to maintain
> something any more than you can force somebody to test something.
>
> 2. We become more liberal with stabilizing newer versions. Lots of
> variations on this, but the bottom line is that packages get stabilized
> that would otherwise not be.
>
> 3. We drop stable keywords on packages. Lots of variations on this as
> well, but the result is mixed-arch systems or dropping stable for the
> whole arch.
>
> I don't think #1 is really the answer - it just results in less-visible
> problems and a stable that is probably works worse than either #2 or #3
> would yield.
>
> #2 has the advantage that it gives us more control over what gets
> installed on stable systems and you don't end up with mixed keywords.
> The downside to #2 is that the user doesn't have as much visibility into
> which packages are "really" stable. Maybe an in-between quality tier
> would help (if you're going to run a mixed keyword system, at least use
> this version).
What about a third "target-stable" keyword? Either arch-teams or package-
maintainers (with maintainers getting priority in case of differing
viewpoints, just as arch-teams already have priority over full-stable)
could set this, and it would let users who wanted to be "almost stable
but hasn't gotten thru all the hoops just yet" arch-testers do just that,
see and test almost-stable packages.
An open stabilization bug would be required for any target-stable
package, and only one target-stable per-slot per-arch would be allowed --
if there's already a target-stable in that slot for that arch, it would
need to be removed and either that package fully stabilized or the new
one substituted in the target-stable slot.
* Note however that different archs could however have different target-
stable packages within a slot. This would allow a maintainer to set a
minimal version target-stable keyword for lagging archs, while setting a
preferred version target-stable keyword for current archs.
A maintainer facing lagging archs could then set target-stable
appropriately, and could re-assign any bugs on the old-stable version to
the arch in question, with comment boilerplate to the effect that the
arch is lagging and hasn't updated stable, so they get to deal with bugs
for their ancient-stable version.
A variant on the theme would be to split the current stable keyword in
half, arch-stable and maintainer stable. Any package version keyworded
for both would be considered fully stable, but the two halves would then
be fully independent, no longer interlocked, and for half-stable packages
bugs would be assigned to the stable side with the other side CCed. In
this variant, there'd be no limit on the number of package versions that
could be half-stabled by either half, just as there can now be multiple
stable-keyworded versions, and for that matter, multiple testing versions
as well.
> #3 has the advantage that it makes the problem directly visible to the
> user. However, the solution ends up being entirely user-discretion.
Either target-stable keyword variant above would be directly visible to
the end user as well, and of course they could choose full-stable or half-
stable on either side as they wished.
> Some users end up on ~arch for life, others do it version-by-version in
> which case they end up on various versions. Personally I run stable and
> when I need to run unstable on a package I tend to use <cat/foo-major+1
> syntax so that I'm tracking unstable until the next major version and
> then I get a chance to revisit the decision - usually stable catches
> up by then.
Interesting. Nominally I do ~arch as for me stab?le== , but I do more or
less the same thing at the overlay-~arch/unkeyworded/masked/live-9999
level.
For my kde packages, for example, I run the overlay and normally
package.keyword/package.unmask 4.y.9999 as soon as it's available in the
kde overlay (I have scripts that do git log --color --stat --graph
$branch ORIG_HEAD.. on the overlays, and routinely run them after
syncing so I know what's going on). But since upstream kde doesn't split
a branch until the rcs and thus those branches and the kde overlay
packages based on them don't appear for the betas, I have to switch to
-9999 during the kde betas, and "downgrade" back to 4.y.9999 when
upstream branches and the 4.y.9999 ebuilds appear. I suppose one of
these days I'll setup kde-frameworks and be doing about the same for it,
too...
What's nice is that for kde 4.12.9999 for example, when gentoo/kde was
still sorting out the masking/dependencies issues in the overlay due to
plasma/workspace being locked to 4.11.x, I was able to grab the 4.11.9999
unmask files from the overlay, do a global search and replace 4.12.9999
in place of 4.11.9999 but keeping the 4.11.9999 for workspace packages,
set a few KDE_OVERRIDE_MINIMAL=4.11 via package.env, and go to town with
4.12.9999 before gentoo/kde had finished sorting out the masking and
dependency issues themselves. =:^)
Of course for kde there's the -4.x.9999 versions to use. For openrc,
etc, there's not. There it's -9999 or ~arch, and for openrc in
particular I use -9999 because the ~arch ebuild changelogs simply aren't
detailed enough and it's too difficult to track down the bugs when they
inevitably appear. Git log and if the commit log is interesting enough,
git show <id>, is far *FAR* better! =:^)
Unfortunately, while it might have been useful for devs, git-r3 has sure
been a headache for users trying to follow upstream development with git
log ORIG_HEAD.. There's workarounds, but they're a lot more hassle with
git-r3 than git2 was. =:^(
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ 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 --
2014-01-14 21:37 [gentoo-dev] rfc: revisiting our stabilization policy William Hubbs
2014-01-15 9:54 ` Michał Górny
2014-01-15 12:51 ` Rich Freeman
2014-01-15 21:41 99% ` [gentoo-dev] " Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox