Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> writes: > On 11/04/2012 12:17 PM, Michael Scherer wrote: >> And I am doubting that changing the release model will suddenly make >> people do QA. > Adam's point is that reducing the number of branches requiring QA should > permit more thorough QA with the scarce resources available, resources > which currently are spread too wide and too thin with the current model. I understand his hope that it would help, but TBH I think it would make things worse not better. Consider: * Currently, we get barely-adequate QA on the frontmost Fedora branch and none to speak of on the back branches. (Certainly for my packages, the standard update cycle is "push update to testing, wait however long bodhi makes me wait, push to stable" because nobody ever adds any karma except maybe in the latest branch.) That's tolerable, actually, because you're not supposed to push anything but low-risk bugfix updates into the back branches. If you think it needs testing you probably shouldn't be pushing it there. * In a rolling release model, however, major changes are supposed to eventually get pushed into all the branches. Each time one gets pushed further back, an appropriate amount of QA would need to get done, if you want to have any expectation of not breaking that branch. This looks like *more* QA to me, not less. The core problem I see here is that in a rolling-release environment, there's nothing to ensure that major multiple-package-affecting changes hit the "stable" branches in a consistent order. That means that each time you push one back, you are creating a unique new package set with a unique new set of potential issues, and that's why QA would actually be needed. Now it's easy to see how to avoid that: force consistency. But that idea leads you right back to the series-of-releases approach that we have now. regards, tom lane -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
