Fedora 23 Final RC10 status is GO !

Chris Murphy lists at colorremedies.com
Sat Nov 7 08:19:52 UTC 2015


On Wed, Nov 4, 2015 at 3:30 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Tue, 3 Nov 2015 09:23:49 +0100
> Petr Spacek <pspacek at redhat.com> wrote:
>
>> On 3.11.2015 01:56, Kevin Kofler wrote:
>> > And with my proposed change to the release
>> > policy (slip = unfreeze, sync all updates, refreeze), you could
>> > also use the time to get fixes/improvements in that would have
>> > otherwise missed the release.
>>
>> +1, this seems like a very reasonable proposal to me.
>
> The problem here is that a slip is a week.
>
> Right now, if we slip it's usually just a bug or two and those get
> worked on and we spin a new RC and test, etc.
>
> If we did this it could mean potentially lots more blockers, so it
> could leed to longer slips. Also, it could make changes such that
> things don't even compose.
>
> But it's an interesting idea.
> I'd love to hear what QA folks think about it.


Very frequently in such cases the entire test matrix is not completely
retested. A lot of prior tests a carried over because they're known
(or strongly suspected) of not having been touched in any way by the
fix of one or two blocker bugs.

If hundreds of packages get unfrozen and sync'd all bets are off. The
state of the release is now sufficiently non-determinstic that it
means all testing has to be started completely from scratch. So I
would say no, this isn't a good idea, just because the resources
aren't there to do this additional amount of testing.

The goal isn't to have a release that's super current. It's to have a
release that's stable and works.

The proposal could be attempted for alpha to see what happens in a
less detrimental fashion. But for final, it's already enough of whack
a mole, and this would be like putting the moles on fertility drugs.
Or throwing a deck of cards up into the air to shuffle it. Or...


--
Chris Murphy


More information about the devel mailing list