On Thu, Dec 04, 2014 at 09:39:35 -0500, Matthew Miller <mattdm@xxxxxxxxxx> wrote:
For us, that would mean alternating between concentrating on release features and on release engineering and QA process and tooling. During the "tick", we'd focus on new features and minimize unrelated rel-eng change. During the "tock", we'd focus on the tools, and minimize change that might affect that.
Presumably we wouldn't need to do this even up. We want say 2 to 1 or 3 to 1.
This is meant to * allow us to continue improving release and testing infrastructure without needing another long cycle
I am not sure that this will really work. The issue with testing was the testing team didn't have enough time to test and to develop. That is still going to be an issue for release emphasizing tooling. I think, for this one, recruiting more help is a better answer.
* prevent compounded delays caused by intersection of feature needs and releng changes
There was a bit of that this time. But this was a really big change. Are you thinking we will have this scale of change for releng on a regular basis?
There has also been some previous talk of a "polish" release, where we focus exclusively on bug-fixes big and small, and delay big features, including holding GNOME and other showcase software to the same version. That's a possibility still, but it would require significant collaborator consensus to really make work, and I don't think we have that. (We still have "first" as a foundation, after all.)
I think delaying big features for distro wide polish goes too much against our First objective. Having people work on bug fixes and other polishing that doesn't block unrelated development is always going to be welcome.
What do you think? Would this help towards the goals listed above? Would it help _other_ things? What downsides would it bring?
I don't think we should force this. I think when developing goals for releases we look for conflicts and defer some things where there is a potential conflict. We'd want to make sure that desired goals eventually get done and not keep deferring the same goal repeatedly (because of conflicts).
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
