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. 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. 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? Also, it isn't the first time an update for different dist releases is tested by different people and receives different feedback. 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. And where packagers insist on rushing out an update for all dist releases, do that _at the same time_ (if not latest dist first). Strictly avoid the _simply bad_ scenario where F(N-1) is ahead of F(N) in terms of RPM version comparison. No matter what reason it may be. Unless perhaps it's the special case of a security update where fixes aren't the same for all dists. Once F(N-1) is ahead for various reasons, you're a stuck with the badness (extra bad for unresolvable deps and ABI/API breakage!) while a solution must be found for F(N) even more quickly - let's hope the packagers don't give up instead, see further below. Bodhi gives too much power to a very few fanatics, who even fetch builds from koji just to get even more updates. Don't tell me that everyone of those very fast +1 voters (even without entering any words as comment) really needs each and every of the updates. Releasing them as a mass-update to all dists at the same time would be just fine. > 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. You publish the _test_ updates for all dist releases at the same time. You collect feedback from testers, but without automatically pushing to stable unless the updates are pushed to all dists _at the same time_. > > If that > > were accomplished, dist upgrades would work much better. Users would never > > find packages in Fedora 21, which are "older than" updates for older dist > > releases. > > At the cost of entirely unnecessarily slowing down the update process, > and annoying maintainers to the point they'd just give up. Uh *sigh* too easy to give up? Package reviews? They suck, because they reveal how flawed a package might be. Let's give up and boycott the Fedora package review process. The Update System? Gah! An unnecessary hurdle. Let's give up and wait for Fedora to open up the infamous dumping ground for untested packages. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
