fedup f20->f21 kde broken deps

[Michael Schwendt]

On Thu, 04 Dec 2014 03:35:20 -0800, Adam Williamson wrote:

> 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.

No, it isn't. [insert Monty Python Argument Clinic sketch here]

Probably you added to much to "the rule" to turn it into a final rule rather
than a base to begin with. It would be nice to know whether a test update
works for the latest dist before even considering making it available
for an older dist (which often is built upon older/different frameworks).
That's why I wrote "If that were accomplished". I mean, if a few testers
of F20 believe the test update works, but it causes trouble for F21, that's
a bad situation.

> "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.

F20 + updates must not be newer than F21 + updates.

*That* is the important scenario to begin with.

F20 + updates-testing newer than F21 + updates is a corner-case, which
would be less of a problem, if F21 + updates-testing contained the same
update that would not be marked stable after doing that for F20.

Seriously, I don't suggest a sane upgrade path either for people, who have
installed packages from koji. But to upgrade from F20 + updates-testing
to F21 without updates-testing clearly is a corner-case.

> > 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.

It should not happen. Not before release of F21 final. Not after release
of F21 final. Especially not _after_ release of F21 final.

If it happens _before_ release of F21, it leads to bad experience from
people who want to evaluate F21 early and find that a fresh install is
the only option whereas an upgrade of a older dist runs into broken deps.

> 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?

Drama time. I already pointed out that security fixes may need special
treatment. But a "showstopper" so late for F20? Come on! What has gone
wrong there? Has it crashed since F20 release or because of a poorly
tested "stable" update? Not mentioning the %{?dist}.N versioning guidelines
here for old-release bug-fixes. ;-)

> > 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?

What kind of question is that?
Have you not observed any packagers in bodhi, who push to stable
manually with "0 karma" and >=0 karma for older dist releases?

> 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'.

That would be nice to have, but it makes no sense to discuss this with
you. With the same test update in F(N) updates-testing it's not a big
problem unless the F(N-1) test updates gets marked stable before F(N).
NTH but if test updates (even version upgrades) of packages are handled
like hot potatoes, there won't be sufficient testing anyway.