Roland Mainz wrote:
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
1) this putback is done
This is review *for* this putback, but...
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.
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.
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.
-- Rich
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
