On Thursday, December 8, 2016 9:17:14 AM CET Matthew Miller wrote: > Trying to make this idea a little more concrete. Here's two suggestions > for how it might work. These are strawman ideas -- please provide > alternates, poke holes, etc. And particularly from a QA and rel-eng > point of view. Both of these are not taking modularity into account in > any way; it's "how we could do this with our current distro-building > process". > > Option 1: Big batched update > > 1. Release F26 according to schedule > https://fedoraproject.org/wiki/Releases/26/Schedule > > 2. At the beginning of October, stop pushing non-security updates > from updates-testing to updates > > 3. Bigger updates (desktop environment refreshes, etc.) allowed into > updates-testing at this time. > > 4. Mid-October, freeze exceptions for getting into updates-testing > even. > > 5. Test all of that together in Some Handwavy Way for serious > problems and regressions. > > 6. Once all good, push from updates-testing to updates at end of > October or beginning of November. > [..]
I'm lost. I'm against prolonging delays before pushes from updates-testing to updates if there's given karma, even for non-security stuff. If that's not enough, we should shape the karma-process. > Option 2: Branching! > [..] Sounds really complicated to me. What's the purpose? -- I probably lost the context ... what real-world problems are trying to fix? Everything which comes to my mind should be solved by better tooling for updates-testing testers. Have you considered the recent "bodhi for rawhide" proposal, too? Pavel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
