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