- 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.
AFAIK there are at least two justifications for such a *.diff:
1. The old ksh88 in the Solaris tree was hacked to death in various bad
ways, making it impossible to track changes without causing potential
harm for older bugfixes. AFAIK Sun has a SCM for those sources but
somehow this failed to work. IMHO such a policy is mandatory to prevent
current and future maintainers to play around with the codebase randomly
and causing it to diverge from the upstream sources which may result (in
the worst case) incompatibilities between our version of ksh93 and the
upstream version. THIS MUST NOT HAPPEN AGAIN!! And yes, I am trying to
There's no need to shout.
Actually, the reason ksh88 is in the shape it is is that it's fallen
into disrepair. There have been various bug fixes to it over the years
but no substantial attention has been paid to it. When it was "ported"
to Solaris, my guess is that nobody knew at the time that David Korn
and ATT would eventually open source "ksh" and that ksh93 would appear
at some point.
be adamant in this case since I do not want to see the ksh93 in Solaris
fall into pieces like it happened with the old /usr/bin/ksh. We really
need an additional safeguard. The whole ksh93-integration project uses
interoperabilty as it's foundation, that's why we had all the main other
many months over three ARC cases to get it "right".
There are other ways of safeguarding this. For one, random people
aren't going to be able putback changes. As with other source code in
OpenSolaris, there are processes to make sure the right thing happens.
Sometimes things happen (bugs get introduced) but usually the processes
prevent the sort of thing you fear happening. And in the case of
externally derived open source, gratuitous changes are highly
discouraged and need justification.
2. We'd like to update many many times, keeping ksh93 in Solaris in sync
with the upstream development. This will likely result in half a dozend
or more updates per year and a seperate patch which tracks the
Solaris-specific changes is very usefull to back them out between
updates (without having to mess around with a SCM; the update procedure
should IMHO be completely SCM independant). It also allows tight control
over Solaris-specific changes to the AST/ksh93 codebase. In theory all
patches should be submitted to upstream, NOT to the Solaris codebase.
The *.diff policy should remind maintainers that changes should go
through upstream and then make it into Solaris with the next source
update from upstream.
I'd like to suggest that although everyone wants the latest features
coming down from ATT and there's certainly a benefit to getting some
early exposure in some cases by integrating changes often, what we
value in ON is a more deliberate, thought-out sets of changes. These
typically might be keyed to a new version or something. It's often
said that the ON gate (or really, any consolidation's trunk) is no
place for experimentation or debugging the project into existence.
Anyone who is patching files in
usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/ and usr/src/cmd/ast/
without storing diffs+READMEs in usr/src/lib/libshell/misc/*.diff will
be <insert-some-horrible-torture-here (gatekeepers should decide how the
punishment should look like... I'd suggest the usage of deep pits filled
with komodo dragons, hot iron, boilling acid etc. (in random order))>.
Actually, that's completely unnecessary. What usually happens is that
instead the ON CRT (change review team)
http://opensolaris.org/os/community/on/crt/
will ask if the right set of people have reviewed the code. If there
is a change proposed to ksh93 and you're not listed as one of the code
reviewers, I would typically put such a request on hold and ask the
submitter to have you review the changes.
I'd like to see an
explanation of why you can't just use the SCM to fulfill your needs. (I can
accept one may exist, I just don't see what it is...)
See above. Basically I do not want to see that ksh93 in Solaris sufferes
the fate of the old /usr/bin/ksh. Somehow Solaris-specfic changes should
be kept at the smallest possible minimum level (and I am already not
very happy (or better: grouchy) about the cut-down list of builtins but
accept this as a oblation to Solaris's backward-compatibilty policy. But
it still hurts me... ;-( ).
It won't fall into that sort of disrepair as long as the community
values the project and honors the process. Yes, mistakes might be made
at times but those can be remedied.
dsc
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
