[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[Stephen Hoffman]

On 2016-10-07 00:47:21 +0000, David Froble said:

> Stephen Hoffman wrote:
> 
>> I listened to folks at the boot camp try to shut down some proposed 
>> cluster-related changes, and without even knowing what those changes 
>> might bring them.   Without even knowing what those changes were.    
>> That approach is problematic.
> 
> You, sir, are way too kind ....
> 
> How can anyone oppose something they don't know, and don't know what it 
> would do?  My description would be a bit more caustic.
> 
> Now, don't you use this to point out my lack of knowledge about C and *ix ...
> 
> :-)

The other half of that was around how and where such questions get 
asked.   This from experience doing product and business management, 
polling and A/B; from making mistakes and from learning from mistakes 
of others.   If the proposed changes are valuable enough and important 
enough to warrant the implementation effort — I've love to hear how 
longer-page support in EDT was a dependency within the x86 port, but I 
digress — then go design and implement and make the changes.   We'll 
deal with it.   We'll upgrade if the changes are of sufficient valuable 
and/or if the disruption is warranted and/or if we require support.

Asking these questions and asking "permission" for incompatible fixes, 
incompatible improvements or more constrained upgrade paths is always 
going to get you a contingent of negative responses.  Always.  You're 
always going to get asked for complete compatibility, for no end-user 
source changes, and no downtime and no disruptions.   Changes such as 
finally ditching DECnet, and going all-in on better IP support and — 
far beyond what is planned for VSI IP — IP integration are inherently 
going to receive (some) negative responses.   Changes such as what gave 
us the complexity of the 64-bit addressing design lead to other 
problems.  That 64-bit addressing design — a quite marvelous design — 
was short-term and compatibility entirely overriding long-term.   But I 
digress.

If you're not sufficiently certain about the value of the proposed 
changes, then either find some other and better changes to make, or 
have the courage of your convictions and your decisions and just go 
make the changes.

If you want or need A/B testing — and that testing could have avoided 
more than a few of the messes in the OpenVMS APIs and UIs, but I 
digress yet again — then assemble a representative group, and present a 
session and walk folks through the benefits and the trade-offs and ask 
your questions at the end.

Yes, these sorts of changes need to be for clear and good reason(s).  
If the changes are going to break compatibility or lead to the 
deprecation of a UI or an API, then design the new API better and/or 
break enough of the existing API all at once, such that we don't need 
to come back to this same area with incremental fixes and changes with 
every release.  Don't dribble out the changes.



-- 
Pure Personal Opinion | HoffmanLabs LLC