[sle-beta] Network missing pieces

[Richard Brown]

On Mon, 2017-11-06 at 11:48 +0000, Joe Doupnik wrote:
>     Without meaning to start a long discussion, I have the distinct feeling here that we have another classical "could versus should" situation. 
>     In my view, the customer/end-user/human experience has high precedence about many matters of this kind. Thus classical tools ought to remain until there are clearly superior versions together marked need for those superior versions. If no such need then the classical ought to remain intact because the goal is to provide the end user with easy to use and remember controls, rather than play with the toys just because one could. There is also the unnecessary complexity part of things where replacement commands for standard straight forward operations require obtuse replacements and extra bits. Example: to open the house front door please hold the key upright in the mail slot         while pointing one's left hand at the door's top hinge, which demonstrates our new nifty electro-optical lock mechanism (void during hurricane season).
>     The aspects of need and complexity become evident when dealing with more than one particular edition of Linux and with our sundry scripts and helpful programs which depend upon such features. Consider these aspects under stressful conditions involving many sundry Linux machines and there is some kind of trouble which must be fixed immediately by a duty manager. Consider what new customers would expect to be available [cf. the Windows 10 start menu fiasco].

"could" we install a package, by default, on all of our customers machines, which are intended to be supported
for 10+ years, when the upstream of said package has been abandoned for over 8 years?
Especially when the old tooling doesn't use many modern kernel features, many of which are required for fully
supported SLE features like infiniband?
And when the new tooling is both actively maintained and has been the designated successor for net-tools for 7
years, and developed for over 10.

Sure, we "could", but the question then becomes "should" we?

And I think it's the height of reasonableness to not inject a poster child example of legacy software on every
SLE-15 machine by default.
Like I said, it is still around as 'net-tools-deprecated' for those users who have no other choice, but a
major new SLE version is exactly when we "could" and "should" make the necessary changes to distance ourselves
from long abandoned tooling that no longer interacts with key components, like the kernel, in the correct way.


-- 
Richard Brown
Linux Distribution Engineer - Future Technology Team
Chairman - openSUSE
  
Phone +4991174053-361
SUSE Linux GmbH,  Maxfeldstr. 5,  D-90409 Nuernberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton, 
HRB 21284 (AG Nürnberg)