On Thu, 2014-12-04 at 12:12 +0100, Michael Schwendt wrote: > On Thu, 04 Dec 2014 02:25:21 -0800, Adam Williamson wrote: > > > How are you supposed to build > > a perfectly legitimate minor version update for all three > > currently-supported releases at the same time, with that rule? > > _At the same time_! > > Publish the minor version _test_ updates for all the releases at the same > time, but ensure that they are marked stable _at the same time_, too. But that's a violation of the rule you suggested. "Packages in Fedora 21 + Updates MUST be "newer than" anything available for older dist releases. With "anything" including updates-testing." If you have foo-1.0 in f20 and f21 updates, then you submit foo-2.0 to u-t for both at the same time, you break that rule, because foo-2.0 in Fedora 20 updates-testing is newer than foo-1.0 in F21 updates. > Or not at all. Don't rush. Avoid the "first come first served" mentality > where F20 is considered sort of "the flagship" while people believe they > need to wait some months for F21 to become more stable. That's not what happens. Updates tend to go stable for the most current stable release first because overall the most people are running it, so it gets the most feedback. And then Branched goes into milestone freezes. F21 has been frozen for Final since 2014-11-18; are maintainers supposed to not push anything stable in F20 for that whole time even if they have a matching/newer build for F21 which is just waiting on the freeze to be lifted? What if it's a security fix? A showstopper crasher fix? Why punish F20 users? > F21 should come > first with any minor version updates. Connect the mass-dist updates to > eachother somehow. Avoid that an update is marked as stable for F20 while > other testers have run into regression with the build for F21. F20 has been > broken since release already or since the last update, why rush? When things are broken, people like them to be fixed. > Avoid the assumption that an update is "good" for all releases just > because 1-3 people have given an early +1 via bodhi for an older dist > release only. Um. What assumption is that? > > You can't, because as soon as you send the new build to F(N-1) > > updates-testing it's newer than the build in F(N) updates. > > You asked about pushing updates _at the same time_. > > We don't have > > that rule, because it would be a silly rule. That rule would require you > > to build it for Branched, wait for it to go stable, then build it for > > Branched -1, wait for it to go stable, then build it for Branched -2, > > and wait for it to go stable. No maintainer is going to go for that. > > No. I'm starting to think you may have typoed your initial suggestion, but as written, it clearly says 'F(N-1) updates-testing can never be ahead of F(N) updates'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
