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
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.