/usrmove?

[Adam Williamson]

On Thu, 2012-02-09 at 03:42 +0530, Rahul Sundaram wrote:
> On 02/09/2012 03:16 AM, Adam Williamson wrote:
> 
> > As the release criteria put it -
> > https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria:
> > 
> > "The objectives of the Alpha release are to:
> > 
> >     Publicly release installable media versions of a feature complete
> > test release
> >     Test accepted features of Fedora 17
> >     Identify as many F17Beta blocker bugs as possible
> >     Identify as many F17Blocker blocker bugs as possible"
> 
> Wouldn't preserving the ability to upgrade increase the chances of
> testing the new features and finding bugs?  Does QA team have final say
> on the release criteria

That's more or less how it's worked so far, yes. We don't really have
any formal 'escalation process', but if anyone was particularly unhappy
with the validation process, I imagine it could be escalated to Board
level.

>  and is there a way I can ask to reconsider this?

Certainly: you can propose that the Beta criterion "The installer must
be able to successfully complete an upgrade installation from a clean,
fully updated default installation (from any official install medium) of
the previous stable Fedora release, either via preupgrade or by booting
to the installer manually. The upgraded system must meet all release
criteria" be turned into an Alpha criterion. You'd do this by posting a
message to the test@ list, quite simply, that's all there is to it.

We don't have a very formal 'voting process', so far we've simply done
things by consensus; it's usually the case that we're able to come up
with a resolution that everyone, or perhaps everyone except one person,
agrees with. If we ever get a very controversial proposal I imagine
we'll have to come up with something better, but for now that's what
we've got.

I personally would likely be opposed to such a change, just on the
grounds (as stated earlier) that we really can't get too strict at Alpha
stage. Remember, people always want us to stop slipping releases, and
the slips quite often happen at Alpha stage. ISTR upgrading was broken
at Alpha stage in F16; if we'd been obliged to have upgrading working by
Alpha, maybe the F16 release would have been delayed *another* week, and
QA and anaconda teams would have lost even _more_ sleep. As long as
we're sticking to six month release cycles, giant feature lists, and
short freezes, there has to be a recognition that we can't demand too
much in the release criteria; it just won't be practically manageable.
(The cynic in me would point out that, when we're just shootin' the
breeze on devel@, people are happy to demand 'more quality' out of the
validation process...but when the release is delayed by two weeks and we
in QA are holding out for a bug to be considered a blocker according to
the criteria, suddenly everyone's pressuring us to 'just let it go and
get the release done already'...)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net