Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Patches?
Randy E. Reinhardt flatly stated:
>> >I have also noted with increasing frequency you folks adding 'enhancements'
>> >to the p series - look folks, that is for the i series, leave the p series
>> >bloody well alone for features and concentrate on just fixing bugs. And
>> >while you fix one bug don't add three more in the process please.
Kevin (the man of a million e-mails) replied:
>> As you probably know, you are not the only person who has
>> commented on the problem with patch releases and new bugs. Taking into
>> consideration all of the comments that we regularly get on this subject, we
>> have made some radical changes to how we will be releasing software in the
>> near future. What we are seeing today is the tail-end of the "old way".
To (mis)quote the Humphrey Bogart movie "The Treasure of Sierra Madre":
"Patches? We Don't Need No Stinking Patches!"
The Ascend microcode has reached the same point of complexity
as Unix System V, Release 4.0 did when we added several dozen
file system types to the source code, in that one must make
either/or decisions which result in no single machine/user
using "all" the code. The complexity of the source tree has
become too much for the original scheme of a single coherent
code base that could be used on multiple products.
I have observed the following (simply from reading the list):
a) Machines which have very little in common
are sitting on the same code base.
b) Users with very different applications are
sitting on the same code base.
c) While there IS a basic "core functionality"
that should be in a "code base", much of
the more esoteric functionality is mutually
exclusive.
d) The size of the "omnibus code" is approaching
the total memory size of midrange cash-cow
machines like the Maxen.
e) The complexity inherent is supporting multiple
mutually exclusive applications in a single hunk
of code is well represented by the bulk of the
Really Useless Big Book (RUBB®) and the size of
the contents of the Sightly Less Useless Random
PDFs on CD (the "SLURP®" CD).
e) The unintended side-effects of a new release
can be drastic. Ascend's simply cannot fully
test for all possible variations. The code
simply has has too many modules.
What this group can do is HELP ASCEND by simply stating
what features they use and what features they do not
use on what products. This will help Ascend break up
the code into true "core code", and a series of compile-time
directives which can create "flavors" of their code for
each machine.
An obvious case is "routing protocols". I would bet that
any one machine runs no routing protocol, or runs only one.
Why include multiple protocols in the "base code"?
I would suggest that Ascend set up a new subdirectory in
their FTP site, and ask all sites to send in sample configuration
files that represent their use of the products. This would
help Ascend to see what is being done with their products.
Ascend could then "unbundle" the code, and offer "ports"
of the code, each for a major subset of the need, each
with some number of major hunks of code REMOVED.
Less can be more. More manageable.
NB: "R.U.B.B.®" (or "RUBB®") and "SLURP®" are Trademarks of
The Bedford Advanced Technology Test Lab Effort (BATTLE®)
in the US and other countries. Anyone using these
Trademarks must do so with tongue firmly planted in cheek,
or face the wrath of our very bored attorneys (who have
nothing better to do than protect this sort of so-called
"intellectual property").
Surfing the electromagnetic spectrum, looking for that perfect Hertzian wave
james fischer jfischer@supercollider.com
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>