On Thu, 2012-11-29 at 05:38 -0500, Marcela Maslanova wrote:
> Lacks clarification on what's considered an feature.
>
> Arguably it should be mandatory for feature owners to provide or work
> with the documentation and or marketing communities documenting and
> publishing what benefits changes their feature brings to
> users/community/the distribution in whole etc.
>
> it's just absurd having us ( QA ) adjusting release criteria while we
> are trying to follow it so feature that might affect the current
> release
> criteria and or critical components will need to be approved by QA
> before alpha so we can but not be limited to making the necessary
> changes to the release criteria in due time and make sure proper
> testing
> takes place and each approved feature arguably should have associated
> test day with it ( if relevant ).
>
> Will it still be optional to participate in the feature process?
>
> JBG
The discussion about features on f-d could help QA to focus on important
changes, don't you think? Or would you prefer something else what
could help QA?
I'd rather see feature process for wide system changes mandatory. People
are complaining about features, which went terribly wrong. I don't see
any other way than control their progress better and help feature owners
with stuff around (broken dependencies etc.).
Also in the past some features weren't announced at all and than later
added because they didn't work well. For example upgrade of Java (I'm not
picking on Java, just remember this one, but there were surely more).
I'm not sure you two are necessarily disagreeing with each other.
Johann's mail implies a distinction between two types of feature, which
is a common theme of this discussion, and to an extent encoded in your
draft, Marcela:
"so feature that might affect the current release criteria and or
critical components will need to be approved by QA before alpha"
I think ultimately Johann's mail boils down to a suggestion for how to
categorize features - by whether they stand a realistic chance of having
an impact on release readiness - and a suggestion that features which
fall into this category should require QA signoff.
Speaking personally - not for the QA team, we do not have an agreed
position on this proposal - I'm always reluctant with the concept of QA
'approval' of a feature, I don't think it's appropriate for QA to have a
veto on the approval or rejection of a feature in toto. But I agree with
Johann that QA can provide important input about whether a feature will
be sensitive from a release readiness point of view, and what needs to
be done for such features to try and ensure they don't cause release
delays: viable contingency plans, test planning, code completion points,
etc etc.
I'm not sure I want us to have a no-matter-what line-item-veto on
features, but I do think we should be able to set a very high bar for a
feature which looks like it could be seriously disruptive to release
quality and which does not appear to have a viable contingency plan, or
a realistic development schedule, or something like that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net