Inicio del mensaje redirigido:
Fecha: Mon, 19 Dec 2011 10:35:48 -0600
Desde: Dennis Gilmore <dgilmore(a)redhat.com>
Asunto: Re: F17 QA schedule modification proposal
-----BEGIN PGP SIGNED MESSAGE-----
El Mon, 19 Dec 2011 08:25:41 -0700
Robyn Bergeron <rbergero(a)redhat.com> escribió:
On 12/05/2011 11:43 AM, Adam Williamson wrote:
> On Mon, 2011-12-05 at 11:34 -0700, Robyn Bergeron wrote:
>> On 11/29/2011 04:01 PM, Adam Williamson wrote:
>>> Hi, Robyn. As discussed on the test list this week and at our
>>> meeting, we'd like to propose the schedule modification described
>>> to the F17 QA schedule. Could you put that in there? Thanks!
>> Sorry - this mail got filtered in ways that are all sorts of
>> wrong. :(
>> My only concern with the schedule as proposed is that we are
>> essentially doing the Alpha Test Compose prior to Feature Freeze,
>> which is the point where features should be testable. I've popped
>> in the existing dates below, but I just want to point out that I
>> think we know from past experience that a lot of features don't
>> hit their feature freeze deadline until *on the actual deadline*,
>> which means that we are essentially testing a compose of stuff a
>> full week before I expect people to finish procrastinating and
>> getting their stuff done. We still have the actual release
>> candidate after that, but I don't want us to basically pull in a
>> date and find out that it's not helpful because all the breaking
>> pieces get pulled in/finished after the test compose date.
>> Pre-Alpha Rawhide Acceptance Test Plan #1 2012-01-19
>> Feature Submission Deadline 2012-01-24
>> Pre-Alpha Rawhide Acceptance Test Plan #2 2012-01-26
>> Test Alpha 'Test Compose' 2012-01-31
>> Feature Freeze (Testable|Complete) 2012-02-07
>> Fedora 17 Alpha Go/No-Go Meeting 2012-02-22
>> Test Beta 'Test Compose' 2012-03-06
>> Fedora 17 Beta Go/No-Go Meeting 2012-03-28
>> Test 'Final' Test Compose (TC) 2012-04-09
>> Fedora 17 Final Go/No-Go Meeting 2012-05-01
>> Or it's possible that I'm nuts and it's not worth worrying
>> over. :) We do the Test Compose for Beta a week before Features
>> are required to be at 100%, but of course, they should already be
>> testable/complete at alpha, so the breakage scenario in Beta is
>> far smaller, theoretically.
> I think in practice it's not such a huge deal. As far as release
> validation goes we just don't really *care* about the feature
> process very much.
> The main thing a TC achieves for us is to give us a sanity check on
> the compose process - can we actually compose a full set of images
> at this time, are they crazily over-size, etc - and the ability to
> start identifying blocker bugs. I just don't see that it's actually
> a problem if the TCs contain features that are incomplete, or if
> some feature lands in TC3 that wasn't in TC1. All the work we did
> identifying blockers in TC1 is still likely to be of value, and
> even if TC3 introduces some new blocker, we haven't *lost* anything.
So I've been ... afflicted with "the travel plague" (where I travel)
and also "the death plague" (where I've been wanting to die). I
haven't forgotten about this - I just pulled it up to make the new
mods, but I need to talk to Dennis and make sure he's kosher with
pulling back the Compose dates a week, particularly the Alpha (since
the date the Alpha Compose would move to, 2/7, is also the date of
dropping orphans and branching from rawhide, which sounds like it
might be a busy day.)
Dennis, what say ye? Is that doable or not for any particular reason?
TCS by there nature are throw away and never intended to be
complete or shipable. its to see where we are and whats broken.
replacing the RATS composes with TCS is fine. It should give us a early
warning if the world is broken and its really no more work for me than
doing a rats compose.
So i would say having a TC on the day of dropping orphans is a bit
silly, it should be the day after, to see what we broke.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----