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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
