Richard Lowe wrote:
>
> Roland Mainz wrote:
> > David.Comay at Sun.COM wrote:
> >>>>> - All AST sources are in usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/
> >>>>> and usr/src/cmd/ast/. All files are 100% identical with the upstream
> >>>>> (AT&T) versions except those listed in
> >>>>> "usr/src/lib/libshell/misc/ksh93_solaris_builtin_patch.diff".
> >>>> I don't understand why this is necessary, the SCM will provide you with
> >>>> diffs and their associated comments.
> >> I have to agree with Richard here - putting back the *.diff file is not
> >> necessary.
> >> If there is an issue with the (external) SCM now which
> >> prevents you from being to regenerate your diffs, then please let the
> >> folks at website-discuss at opensolaris.org know. But putting back this
> >> extra file seems unnecessary.
> >
> > IMHO it is neccesary for now. Our codebase is currently hosted on a
> > Subversion tree and not Mercurial. For now I really like to track things
> > this way and EOL it after
>
> I really don't like the idea of leaving crud in the tree, for just that
> reason.
Erm... $ for (( i=0 ; i < 666 )) ; do print "xx@@@!!!... ;-(" ; done #
...
... this isn't "crud". This is an anchor, some kind of documentation and
help for those who maintain the code. If we rip this out we would start
ripping more things out... lets see... "buildksh93.ksh" could be ripped
out (this is the wrapper script which adjusts the native AST build
configuration to generate the AST build+includes for our needs (adn
we'll run into serious trouble if this script would get "lost" somehow
(see my dtksh example at the end of this email))), we could start
stripping all "unused" files from common/, making all upstream files
"cstyle clean", modify some sources and add new "cool" features etc.
etc.
Really... we could do all this stuff... but at some point the AST/ksh93
sources in the tree become unmaintainable and we loose our abilty to
keep the sources in sync with the upstream version. All these "little
wishes" were implemented for ksh88 with the "well known" and very fatal
results.
IMHO the project documentation, the build scripts and the diff should be
stored together in one place and not shattered over many locations. They
all work _together_ and are maintained _together_. Maybe the diff can go
away some day (not now, please) when we can proove that we really don't
need it anymore (AFAIK right now we can't proove that) ... but right now
all these things are really needed by those who are maintaining the
code.
The *.diff and buildksh93.ksh will IMO not "crudding up" the tree as
they are maintained together with the rest of the tree. Please try to
see it like some kind of maintaince aid and documentation (which are
AFAIK both allowed in OS/Net).
> > 1) this putback is done
>
> This is review *for* this putback, but...
My comment was about what may happen after this putback. This is just
the _first_ ksh93-integration putback and we'll expect many many more
than this one... we still have lots of features in the queue and various
updates from upstream. There is still a long long way in front of us...
> > 2) a reasonable plan gets accepted how we can prevent the ksh93 codebase
> > from being overrun with Solaris-specific changes which are not submitted
> > to upstream
>
> Whether they're submitted or otherwise is entirely unrelated (as I think was
> pointed out before), the question is whether they're left crudding up the
> tree. To deal with that, look at changes as they go back using the SCM, or
> as was also mentioned codereview of said changes, which I, too, would assume
> you'd be involved with.
Umpf... as I said this is not "crudding up" (uhm... "crudding" ~~=
"trashing something up", right ?) the tree. It's maintained together
with the rest of the sources and updated (like "buildksh93.ksh" and the
upcoming "usr/src/lib/libshell/misc/touristguide.xml") for each
update/putback to reflect/document the major changes we did and some big
warnings about major "traps" in the code (e.g. things which look
nice&&cool to change but result in nasty+weired bugs (and we've wasted
lots of time with those "traps"... ;-( )).
> > 3) a way to allow offline, non-Mercurial users to update the ksh93
> > codebase without messing with Mercurial at all.
>
> To be blunt, Hell No.
>
> You want a way to interact with the SCM ON will use without ever using it,
> or needing to use it at all? I can't even think of a technical way to
> satisfy this, and to be frank, if I could see one I wouldn't even dream of
> implementing it.
What happens if the SCM becomes inaccessible and/or a switch to the "SCM
flavor of the day" causes a (partial) loss of the history (this already
happens with the switch from the old SCM to Mercurial, right ?) ?
> > Right now none of the conditions are met... and I think we should keep
> > the status quo and defer this discussion to a date after the putback
> > (please...) ...
>
> Again, I don't like it being left crudding up the tree for (what I see as)
> no good reason. You're free to keep these diffs somewhere else if you so
> choose, and you're free to create and manage them as you desire, but I see
> no compelling reason to keep them in the tree.
Oh, that's a "great idea". Small example:
Once upon the time someone wrote a IPv6 patch for dtksh, a test suite
for the change and some documentation. The test suite and documentation
were not put back into the normal codebase and were stored "elsewhere"
in a "permanent storage which will not go away".
Many years later... maintainer gone, author gone, "permanent storage
which will not go away" gone. What remains is the change in dtksh (which
added some weired bugs) and a small echo about the test suite which
noone can find anymore.
Would you really suggest to put something important like the diff and
buildksh93.ksh "elsewhere", like a "permanent storage which will not go
away" ? ;-(
Slightly offtopic: In the meantime I wrote my own version of IPv6
support for ksh93 (this time with IPv6 mobile and multihoming support)
... we really couldn't salvage the patch from dtksh for some certain
reason... xx@@@!!... ;-(
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
