fedup f20->f21 kde broken deps

Adam Williamson adamwill at fedoraproject.org
Thu Dec 4 05:43:14 UTC 2014


On Thu, 2014-12-04 at 06:16 +0100, Ralf Corsepius wrote:

> Untrue. All you need to do is to apply the "after release" update policy.

> I.e.: push updates to "updates" on both Fedora(N) and Fedora(N+1). When 
> you need to cut a snapshot, move Fedora(N+1) updates into the main 
> repository.

Hum. It might be possible to use the branched updates during freezes in
that way, yeah. Have to see what releng thinks.

> > 2. Implement a perfect and strictly-enforced upgradepath test and
> > abandon milestone freezes
> >
> > The consequence of this would be be we'd probably never manage to get
> > the damn milestone releases done because people would keep pushing
> > changes that break them.
> >
> > Neither of those seems likes an improvement on the current situation to
> > me.
> Well, right now, you can't test upgrading and are likely to be broken 
> upgrade paths (as Fedora had always done).

You can test fine; just test with updates-testing. Testing upgrades as a
'release time' test is fundamentally kind of artificial, especially with
our current fedup design, because it's fundamentally not a 'release
time' operation. The only thing it really makes sense to test as a
'release validation' test is the upgrade.img in the frozen tree, because
that's the only element that's tied to release. Otherwise, upgrade is
always a moving target. We can't test what the upgrade experience will
be in a month, or a week, because it uses the 'updates' repository in
most configurations.

Just for the purpose of testing upgrade.img, you can simply enable
updates-testing if it turns out you have a situation like this and you
need a package from u-t to make the upgrade package set viable.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the test mailing list