On 12/04/2014 06:43 AM, Adam Williamson wrote:
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.
No.
"updates-testing"'s purpose is to test update-candidate "packages". I.e.
these packages may never end up in "updates" for a variety of reasons.
"updates" purpose is to provide updates to packages in "release".
i.e. they must integrate perfectly into release.
The difference is important in release preparation stages of a Fedora
release.
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.
This is not true. They are completely different scenarios.
The purpose of using "release"+"updates"+"updates-testing" is entirely
different from using "release"+"updates", esp. in stages like these.
The purpose of using "release"+"updates" is to test upgrading to
Fedora(N+1) (and testing fedup/yum/dnf-support ) and not to test
update-candidate packages from "update-testing".
Ralf
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
