On Wed, 2012-02-08 at 12:20 -0800, Toshio Kuratomi wrote: > Now it's quite possible that if QA doesn't care whether anaconda upgrades > work until beta that the feature policy could stand to be rewritten here. > Perhaps we could say that Features do not need to be testable in the upgrade > scenario until beta, for instance... I'm not sure that really makes sense, > though.... If we have a failure to communicate between the feature owners > and the anaconda team (as happened with the feature owners and releng this > time) it might be that the anaconda team isn't told that new code needs to > be integrated or even written until Beta which seems like a bad idea.... I see your argument, and there's a lot of merit to it. It's entirely up to FESCo to decide how to proceed with this on a feature process basis. As far as the 'feature' side of things goes I don't really have a dog in the fight and am just trying to provide information to this list. As far as things-that-are-actually-QA are concerned: we mostly go by the release validation process, and per the criteria, upgrades have to work by Beta, not Alpha. So as far as QA is concerned the fact that anaconda support for /usr relocation wasn't present until today (it's in now, untested though) is not a huge problem. I personally, and I think QA as a team, certainly don't mind if FESCo decides that, as far the feature process is concerned, it *is* a problem and the feature process should be tightened up to ensure it doesn't happen in future. Hope that clarifies things. -- 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
