On Thu, Sep 22, 2016 at 12:18:53PM -0400, Matthew Miller wrote: > On Wed, Sep 21, 2016 at 12:32:40PM -0600, Kevin Fenzi wrote: > > * IMHO the initial upstream default didn't make sense for Fedora > > On this specific change, I'm not sure the *updated* default makes sense > either. It still is quite constrained. > > > * Perhaps after beta but before final we ping maintainers of > > "important" packages asking what big changes have happened? Or > > someone just goes thru the release notes for them all and proposes a > > list of them? > > I think this is good, but probably too late for some kinds of > decisions. This would help by highlighting things that should be testing… I don't know though if pinging maintainers is the best way to do this, since this would require quite a bit of time from some volunteer. > > * Your brilliant idea here. > > I think that we should have a general policy for packagers of > far-reaching infrastructure packages (systemd, glibc, kernel, whatever) > that any new restrictions or constraints should be disabled by default > in Fedora, regardless of upstream defaults, until we're able to have a > conversation — here, in the edition WGs, and/or in FESCo, as > appropriate for the particular change. Every change of this type is a judgement call. Most of such changes don't cause any issues and if FESCo wanted to review every one it would be swamped with useless work (apart from systemd, at least selinux introduce new restrictions every once in a while). I'm sorry about TasksMax causing issues. We should have been more careful in introducing it and phased it in by first introducing it for internal systemd units, and only later turn on the global setting. We'll try to do better in the future :) Nevertheless, for our defense, let me point out that the problems with this change are obvious only in hindsight: after all new systemd versions are only introduced in rawhide / pre-beta, and this was added in 228, while F24 was released with 229, so systemd with this change passed through the usual testing without people reporting the issue. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
