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