>>> - 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.

> 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

Reply via email to