Danek Duvall wrote:
> On Wed, Mar 14, 2007 at 10:28:03PM +0100, Roland Mainz wrote:
> > > As far as I can tell, there aren't any good options. There's a tension
> > > between the way ON works and the way that projects not developed for ON
> > > work.
> >
> > Uhm... that's not 100% correct... we've spend almost the whole time in
> > the last twelve months to adopt ksh93 for Solaris+OS/Net. Much of the
> > bugfixes, cleanup, design changes and quality work&&testing were done
> > exactly because we're targeting OS/Net and it's stricter rules for
> > putbacks.
>
> I know you have. But I believe that much of that work (and associated
> anguish) would not have been required -- all this mess about unreferenced
> files, for instance -- had you been targeting SFW, for instance.
Umpf... right... but that is partially a result because the ksh93
project is _very_ special in many cases. For example the codebase was
initailly not developed for OS/Net, has to maintain portabilty across
more than one platform (e.g. OS/Net vs. rest of the world) and we still
like to maintain some way to do the primary development of "ksh93 for
Solaris" within OS/Net. Another issue which caused confusion here is
AFAIK that ksh93 is feature work - it adds a completely new set of
features which have some unusual properties (like 32bit+64bit versions
of a shell) and (to make it worse) we've added more features during
development (which is unusual for OS/Net, too). It's like aiming on a
moving target while jumping around with the crossbow.
> *Different* messes might have sprung out of that choice, but they *might*
> have been easier to deal with.
I strongly doubt that. We would have saved large amounts of the
"scratching other people's eyes out" now and get larger amounts of
scratching later in all the smaller follow-up projects while fighting
for each single item (see examples below) and create tons of paperwork
and "cross-consolidation mutant flag-days" to handle somehow the
dependicies (assuming this mess would be somehow
controllable/manageable... I guess we would get battle-worn over time
just by the adminstrative overhead instead of producing code and at some
point just give up because we can't handle it anymore...).
> > Picking another consilidation won't help because the majority of items
> > we'd like to touch in one or another way are in OS/Net.
>
> I know. I don't fully understand how these projects will be implemented,
> but if it's a matter of simply a bunch of things in ON using the ksh
> libraries, then a handful of contracts should be sufficient to ensure that
> when the ksh side changes incompatibly, the ON side follows (or leads,
> depending on the nature of the incompatibility), especially because the
> project team is the same on both sides (at least at present).
>
> Well-written contracts can be worked on once,
... and who should do that paperwork ?
> and cranked out multiple
> times pretty much at will, and cross-consolidation flag-days,
OUCH! ... ;-(
You may have noticed that I am already trying to avoid any "flag days"
at all costs. I guess something like a "cross-consolidation flag-day" is
even worse, right ? If "yes"... how should I react in such a case - die
and explode ? ;-((
> while they
> can be painful, needn't be, and can often have a grace period built into
> them without much discomfort.
Uhm... I doubt that this would be much "fun". Think about cases like
/usr/bin/sleep or /usr/bin/printf where something like |int main(int ac,
char *av[]) { return b_sleep(ac, av, sh_init(argc, argv,
(Shinit_f)0));}| would live in OS/Net and the main code would reside in
SFW (e.g. libshell/libcmd/etc.). And that wouldn't be an exception - it
would be AFAIK the general case for all the consumers of "alias.sh"&co.
(see OS/Net closed source).
2nd example (and we have much worse dependices on the ToDo list... for
example... is it allowed to deliver kernel modules from SFW ?) would be
|libc::wordexp()| depending on libshell to do the word expansion - would
it be really allowed to make a central piece of OS/Net like libc.so.1
depend on a piece of software which lives in SFW (ask youself and try to
be honest... :-) ) ?
3rd problem... we would have to replicate lots of OS/Net's build system
and Makefiles in SFW, e.g. we would still have to write our own
Makefiles to get features like CTF support, libraries
filtered through "mapfile-vers", all the smaller optimisation work (like
the the largepage optimisations I added in
"usr/src/cmd/ksh/Makefile.com") etc. - which finally means we do the
same work for SFW as we are currently doing for OS/Net and we would have
to maintain this ourselves instead of having the gate staff and other
people help us.
Short: Putting ksh93 in SFW would not have any advantage for us... in
fact I guess we would run in even greater problems later - more
bickering, more fights, more paperwork and less stricter rules to
maintain the level of quality we've reached in the meantime. SFW would
really the h*ll for us...
> But if you're as (or more) comfortable with the path you've chosen as you
> think you'd be with the other, then please continue.
It's not about being comfortable or something like that... I still
belive that the choice for OS/Net is the correct one. I know... the
beginning was very bumpy but I hope we've found&&identified all major
problems and that getting rid of these issues at the beginning causes a
much smoother ride for the follow-up projects.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
