<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-24 22:53 GMT+01:00 "Jóhann B. Guðmundsson" <span dir="ltr"><<a href="mailto:johannbg@gmail.com" target="_blank">johannbg@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
systemd is now, or soon will be, a core component of pretty much all<br>
major and minor distributions out there and it's no longer just about<br>
you Lennart and your thoughts of whether it's "Yuck!" or not, you are<br>
now similar to the kernel and like the kernel you should have a proper<br>
deprecation process that is not just what you, Kay and who ever the<br>
main developers decide is cool or not at the time. You should give us<br>
and distributions in general more than 4 days to deal with what lives<br>
or not. Ultimately systemd is no longer in nappies and is all grown<br>
up, while you are still it's father it's now a teenager and needs to<br>
be somewhat independent of it's father, it has friends that now depend<br>
on it and there's should be a central place where these architectural<br>
changes and deprecation intentions are announced, discussed and in the<br>
case of deprecation given more than 4 days before removal.<br>
</blockquote></div></div></blockquote><div><snip> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
</div></div>
>From broader view this boils down to how long should unmaintained core os components be kept around</blockquote><div><br></div><div>The way I read Peter's mail, he is referring to TCPWrapName in systemd, removing it less than 4 years after its introduction, with no advance notification to users. (To be clear, this is not a Fedora-specific concern unless someone wants to make it one, and I don't.)<br>
<br></div><div>Independently, looking at <a href="https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=tcp_wrappers" target="_blank">https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=tcp_wrappers</a> , it doesn't seem that tcp_wrappers need much maintenance.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">, which is something that should be hashed out among relevant upstreams in next plumbers session to establish a clear path forward and arguably upstreams should be responsible to make the decisions when things should be deprecated forcing downstream to either adapt new modern way's or maintain stuff downstream with themselves chose they do so instead of adapt.<br>
</blockquote><div><br></div><div>That doesn't work. Unfortunately a common reason to deprecate a component is that the upstream has gone away or become inactive, in which case we can't expect that same upstream to take action to coordinate a deprecation.<br>
<br>And in any case, we shouldn't start with the default assumption that any published Open Source component is by default stable and recommended to be relied upon by other applications, and only "blacklist" those that are known to be deprecated; in fact many Open Source codebases are private codebases published "just in case others find them useful".<br>
<br>We should rather use a "whitelist" approach, choosing and listing components known to be competently designed and likely to be well-maintained in the future, and taking extra care to help them stay that way—moving towards an actual declared API of the OS.<br>
<br>(The Base WG has, as one its goals:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div> Based on feedback from other WGs, provide a API and/or ABI
stability for a specific release rather than simply package
versions/releases<br></div></blockquote><div>) <br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
By the way the kernel does not have a proper deprecation process which is accurately reflected in all the code that is bit-rotting there so it's not the holy grail of code maintenance as you let it out to be.<br></blockquote>
<div><br></div><div>The kernel has built a reputation for having a very simple deprecation process: "Don't" :) And actually it does have a "proper" deprecation process beside that: <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/obsolete" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/obsolete</a> (though I'm not entirely sure how popular / comprehensive this is, at last one time this seemed to be undesirable, opposing the "Don't" approach.)<br>
</div><div> Mirek<br></div></div><br></div></div>