On Mon, 2 Nov 2015 12:45:36 -0500 Neal Gompa <ngompa13@xxxxxxxxx> 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
Attachment:
pgpAKMxhQp1NF.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
