On Wed, Jan 13, 2016 at 2:55 PM, Adam Williamson
On Wed, 2016-01-13 at 10:13 -0700, Chris Murphy wrote:
> On Tue, Jan 12, 2016 at 6:06 PM, Samuel Sieb <samuel(a)sieb.net> 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
> 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
> 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
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.