On 09/24/2016 08:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
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 :)
How did you arrive at the idea that users are in need of no longer
being able to run as many processes as before?
Was there a user report asking for such change?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx