Richard Lowe wrote:
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.
To clarify (and respond to myself, sorry).
I imagine the plan is that you send these diffs upstream, so that the AST
folks can incorporate them (or not) as their desires dictate.
These diffs can be generated by you fairly easily, either from the
changesets introducing these changes, via a straight diff between AST and ON
sources... probably other ways too.
The diff's your suggesting people putback to the tree are the same diffs the
SCM would show you if you were to look through the history of changes to the
ksh93 sources.
This wouldn't involve the AST folks dealing with our SCM, you would be
dealing with it anyway, the diffs would show the same things and wouldn't
rely on engineers remembering to generate them.
I fail to see how this is any harder than putting them back, in fact, I'd
say it's easier and more reliable *and* tidier.
-- Rich
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
