On Wed, Jul 17, 2013 at 2:20 PM, "Jóhann B. Guðmundsson" <johannbg@xxxxxxxxx> wrote: > On 07/17/2013 12:05 PM, Richard W.M. Jones wrote: >> >> On Wed, Jul 17, 2013 at 09:21:39AM +0000, "Jóhann B. Guðmundsson" wrote: >>> >>> On 07/17/2013 12:58 AM, Ding Yi Chen wrote: >>>> >>>> You still have not addressed the third party programs and scripts >>>> that monitor /var/log/messages >>> >>> We honestly cant keep progress and cleanup in the distribution back >>> out of fear of breaking some third party programs. >> >> Irrespective of whether journald is good or bad, this is a dumb >> argument. > > Dumb I see so you have established a time frame for us how long we should > hold back progress in the project and or you have devised an implementation > plan on features and cleanups with a rate that a third party can keep up > with in the distribution, maybe even chosen which third parties we wait for > and which we dont? Progress does not that frequently depend on removing older functionality. Specifically in this case, removing rsyslog does not make journal in any way better. > We as a community need to be able to set the pace for ourselves and the fact > is unless you are closed source the best thing you can do as a third party > is actually participate in the Fedoraproject, packaging you software or > application stack and ship it within the distribution so that our existing > processes will catch any fallout which our features or cleanups might bring > and allow for the community to actually fix it with your or for you. The "we have source, we can improve the API, update all users and end up with a cleaner design" argument is very rarely true in practice outside of fairly tightly coordinating communities (of which the Linux kernel and its approach to internal interfaces is probably the most visible example). In fact, we as a distribution are getting _worse and worse_ in this regard. There are, instead, more and more subsystems that ship parallel-installable versions with no specific plans about ever fixing "all users" - sometimes apparently just hoping that both the unported users and older versions of the subsystem will die of neglect at approximately the same time. The argument about updating all users is just not true for proprietary applications, binary-only applications, or cross-platform applications with a release schedule significantly different from Fedora. (Some people think that the Linux ecosystem should be entirely Open Source, so they don't find this relevant. I'd rather not extend this huge thread into a discussion of this particular difference of opinion.) Finally, as a thought experiment - we have a fairly well developed concept of automated testing, and we (so far?) have Moore's law making CPU, storage and the cost of testing exponentially cheaper over time; it just might be the right thing to do to provide essentially infinite backward compatibility, in the same way the newest Windows can run 64-bit applications completely natively, 32-bit applications almost natively, 16-bit applications in a VM or full software emulation, or even fully emulate old 8-bit systems. The same thinking applies to individual sets of APIs and other interfaces: write the new implementation, write a compatibility layer for old users that replaces the old implementation, write a test suite of the compatibility layer (... or just use the test suite of the implementation thing that you should have already), keep the compatibility layer shipped and running and forget about the transition. Writing a compatibility layer is roughly the same kind of work as porting applications, so with any interface that has at least a handful of users a single compatibility layer should in fact be less work. With this approach, it's not at all obvious that one shouldn't aim for a backward compatibility 100 years back[1][2]. Mirek [1] One can't promise the backward compatibility 100 years into the future, though, no more that one can promise that any particular town/nation/language/building will still exist. [2] Don't worry, I'm not at all proposing that Fedora should aim for a backward compatibility 100 years back. I do want to seriously undermine the idea that progress requires removing or breaking things, though. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel