fedup f20->f21 kde broken deps

[Michael Schwendt]

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.