On Wed, Jan 13, 2016 at 2:55 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Wed, 2016-01-13 at 10:13 -0700, Chris Murphy wrote: >> On Tue, Jan 12, 2016 at 6:06 PM, Samuel Sieb <samuel@xxxxxxxx> wrote: >> > On 01/12/2016 08:37 AM, Kamil Paral wrote: >> > > >> > > Do you have some other ideas/proposals, in general or in some >> > > specific >> > > situations regarding the slip length? >> > > >> > I'm wondering if there would be interest in hosting a file >> > containing >> > upgrade requirements for each version. For example it could have >> > the >> > package version requirements needed for a successful upgrade. The >> > upgrade >> > tool could check that and warn the user. >> >> One of my concerns is the state of ca-legacy, and whether and how >> this >> gets disabled on upgrades. I'm sure there are some other things that >> have ex post facto unsafe defaults that just stick around through >> upgrades rather than being reset to new defaults. In my opinion that >> would violate the Workstation PRD "Upgrading the system multiple >> times >> through the upgrade process should give a result that is the same as >> an original install of Fedora Workstation." > > This all seems out of scope, as Kamil said. Can we please stick to the > non-media blocker policy discussion here? General concerns / ideas for > upgrades, and specific potential upgrade issues, should get their own > threads. > > It's very likely true that upgraded systems get increasingly out of > whack with freshly installed ones when it comes to default > configurations of various packages - especially ones which don't use > the modular, multiply-overridden configuration style, and thus can't > easily update the distribution defaults post-install - but this doesn't > really seem to have much to do with the question of what the release > process policies WRT non-media blockers should be. Yep, it's true my was vaguely, unintentionally, in the vicinity of, a drive-by / hijacking. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
