This is the main thing that concerns me. It either says something
about the way management wants to handle releases, or the way the
code is structured.
Assuming the code is reasonably modular, things like the protocol
stacks are relatively stable and just talk to the interface API.
Sure, change the modem code and things in general will get broken,
but that should touch things like SLIP!
We do a lot of work with Proteon. The engineers there are quite willing
to build an interim release (as what most software people would call
a release candidate) from a stable code load with a given patch applied.
This way a given item or fix can be tested without inheriting a bunch
of Not Ready For Primetime code as well. Once the individual item is
tested it is merged and regression tested with the next code load.
I think people would be ecstatic to get mini fixes which address an
issue at a time. It might not make management happy to release
a large number of "betas" but it would make people happy to know the
problems _are_ being addressed.
For others wondering:
We run 3.7.2 across most of our infrastructure due to SLIP being broken
in 3.7.2c3. Where we can, we have 3.8b13 running and are generally
happy with it. We have avoided b15 for the reasons already stated on the
list.
> Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
-- Jeffrey Haas -+- jmh@msen.com -+- http://www.msen.com/~jmh /\/\sen, Inc. "Michigan's Best Run Internet Service Provider." - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>