Looks like I forgot to reply to this:
Adam Williamson wrote:
> That's ass backwards, though. We need the testing _to determine if the
> things should be in the release_. Really, I think if you look at the
> quality of the releases that have happened since this policy was
> changed, it's pretty clear that it helps. It makes pulling together the
> pre-releases a lot less chaotic.
I'm not convinced… Our previous releases were quite good too!
> We're very clear about what you get to expect with pre-releases, and
> being able to upgrade to the final release seamlessly certainly isn't
> one of those things.
And I think this is both extremely unhelpful and a total disconnect from
user expectations.
> Sure. I don't see that as a huge issue. We explain why it happens and
> provide the solution - distro-sync - and people are generally fine with
> that. I haven't seen anyone who thought it was a terrible idea yet.
Well, now you've seen one. :-)
(And the solution I actually give is: "Try 'yum distro-sync' this time, and
next time you install a prerelease, you'll probably want to make sure you
disable updates-testing before doing anything else, in particular before
installing ANY update…")
> > 2. Updates-testing tends to contain very broken stuff, for which the
> > maintainer knows it needs more testing before being proven usable (or
> > not).
>
> One, that's certainly not how updates-testing is supposed to work, and
What is it for then, if not for testing things to see whether they work or
not? That really SHOULD be how updates-testing SHOULD work. If the
maintainer knows that an update works, it should be in stable, not testing
(which also means the maintainer should be the one making that decision, not
some arbitrary policy…).
> two, I dispute that it's the case in practice. Could you point to an
> example?
For how updates-testing works out in practice, just look at any package with
negative karma. Now, there's some probability that it's one of those
packages where the karma system just didn't work (you cannot just sum all +1
and -1 comments and expect it to sum to something meaningful, building
automatically enforced policies out of this totally arbitrary number just
makes no sense), but still, in many cases, the negative karma is there for a
good reason.
>> Enabling it by default makes Branched more unstable than it could be (and
>> in some cases, even more unstable than Rawhide, as the EVR monotonicity
>> issue which is the subject of this thread shows).
>
> Erm, the update in this thread happened in Rawhide; F16 was not branched
> at the time. If F16 had been branched, the update would never have made
> it out of updates-testing, hence much less of a problem.
Except that updates-testing is enabled by default! Which, incidentally, is
exactly what I'm complaining about.
I think you're missing my point:
> Making it less likely that we'll have to do reversions / epoch bumps is
> one of the *strengths* of the updates-testing system.
Only for those users NOT using updates-testing.
Updates can be pulled out of updates-testing at any moment, which makes a
lot of sense, but which means that users with updates-testing enabled will
end up with the EVR going backwards, something that's not even allowed in
Rawhide.
Enabling updates-testing by default means forcing EVR downgrades on users of
Branched by default, making the policy banning them in Rawhide totally
pointless.
>> 3. People testing with updates-testing enabled aren't testing what will
>> actually end up in the releases (Alpha, Beta, Final), which use only
>> packages marked stable.
>
> Sure. But their testing enables us to make good decisions about what
> *should* go into the release. I don't see where this is a problem.
The problem is that basically nobody is testing the actual release package
set, considering that it's much less straightforward to opt out of updates-
testing than to opt in, and that probably only few people are doing it (and
those who do bother to explicitly opt out of updates-testing are the ones
who just need early access to the releases for whatever reason, e.g. because
they need a newer version of some package, and don't actually want to do any
testing whatsoever, just to seamlessly move on to the release when it's out
officially).
> It's not at all pointless, because the point of the Alpha / Beta images
> is to provide a known-good base. If the Alpha / Beta are broken, you're
> pretty screwed. If an update is broken, just re-install from the
> known-good base and skip the update.
LOL, good luck finding the offending update among the dozens of packages
which will get upgraded in your first update after installing the Alpha or
Beta.
> Oh, and this wouldn't be any different if we changed the policy anyway,
Not true:
Consider the following sets of updates:
* Set A of updates goes stable before the freeze.
* Set B of updates goes to testing before the freeze, gets queued for stable
during the freeze and pushed right after the unfreeze.
* Set C of updates goes to testing during the freeze, gets queued for stable
during the freeze and pushed right after the unfreeze.
* Set D of updates goes to testing during the freeze (or right after the
unfreeze, in the same push where sets B and C go stable) and gets queued for
and pushed to stable only well after the unfreeze.
* Set E of updates goes to testing well after the unfreeze.
The compose obviously includes only update set A.
Assume we are right after the unfreeze:
* Update sets A, B and C are stable.
* Update set D is in updates-testing.
* Update set E is not queued anywhere yet (probably not even built yet).
Current: The user will get offered update sets B, C and D as updates.
Proposed: The user will get offered only update sets B and C as updates.
This would reduce the number of 0-day updates for Alpha/Beta releases
significantly.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
