On 07/15/2013 11:15 PM, Matthew Miller wrote:
On Mon, Jul 15, 2013 at 11:02:09PM +0000, "Jóhann B. Guðmundsson" wrote:
I would assume they take into account hard valid technical arguments
not change in workflow ( which any change might bring ) or people
pluses or minuses but maybe that's just my wishful thinking.
"This has a change in workflow" _is_ hard, valid technical argument. Any
change needs to overcome that in one of two ways: 1) minimize the pain of
transition with compatibility paths, documentation, and serious thought
about the user experience for current users; and 2) bring significant new
value that weighs against it. The best changes work on both sides of the
equation, of course.
Yes we followed that rule of thumb when we introduced those changes with
anaconda/systemd/gnome3 etc ;)
Anyway awhile back I did not file that ticket with FPC rsyslog proposal
just because, with my QA hat on I can say daemon/service solution that
depend on text files something like fail2ban etc. is what we need to be
watching out for and that's where the breakage will be and afaik nothing
has been done to
a) figure out which components those are ( and it will be hard to detect
them all due to components not properly depend on rsyslog syslog-ng etc
or even logwatch for that matter )
b) fix it ( which my FPC proposal was aiming for, with me actually doing
the fixing part ).
c) not seen maintainers that do maintain components that rely on files
in /var/log chime in
But fesco get's to do all that research to properly determine the actual
cause and effects and the scope of removing rsyslog...
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
