On Mon, 2 Nov 2015 12:45:36 -0500
Neal Gompa <ngompa13(a)gmail.com> wrote:
...snip...
I'm hopeful we can get to this with Rawhide prior to the
branching
point, but can our infrastructure handle it? I'm somewhat ignorant
of the capabilities of the Fedora infrastructure...
Yes, as I noted we are working on it.
Perhaps full release validation could occur on composes every two
weeks for branched releases? Or is that still too demanding?
No idea. I don't want to speak for the QA folks.
Could we slip in some settings for TCs that trigger distro-sync
behavior by default on "dnf upgrade"? Or would this still be
undesirable?
90% of the time you can just downgrade a package and it's fine.
However, the other 10% of the time it just won't work. Your postgresql
database will have a different format. Your package will move a
directory to a link or vice versa. The package will have migrated your
settings to the new version and the old version will crash.
I think it'd be pretty nice if we could use our mix of
automated
tests and checks for composing weekly snapshots of rawhide that would
be "installable" and "usable". This is not a particularly new
idea[0], but in light of the openSUSE guys being able to pull it off
with Tumbleweed, I don't see why we can't get there too. It might be
a little more "raw" than Tumbleweed and serve somewhat a different
purpose, but I think it would make testing the state of the
development tree far easier.
Absolutely. We already are. OpenQA has been detecting problems, and we
have been fixing them. I think this will result in a increased amount
of time that rawhide images are installable.
Thats only sort of related to discussions about releases and updates
tho. ;)
kevin