Richard Lowe wrote:
 > No

So, since it seems likely that the ksh93 project will need/desire
to keep this stuff around, where is it expected to live?  As I read
Roland's comments (and, I admit I probably am confused), it seems like
he is desperately trying to keep the original ATT code (makefiles...)
in the source tree.  If only so that the team has a snowballs chance
of keeping in sync with their upstream supplier.

I agree - this is at odds with ON's traditional "anti-portability"
perspective (i.e., it ain't expected to work anywhere else).

Unfortunately, that mindset presumes (incorrectly here) that the
version of the source in ON is the master.  Ksh93 /is/ expected
to work elsewhere, and we can not expect the project team to devote
unbounded resources to the port/transform every time the upstream
supplier (ATT) updates their code.

My suggestion was to make explicit the separation between the code
that ATT delivers and the code that ON consumes as a way to get out
of this rock -vs- hard place.  I don't really care if the baseline
code lives in ON, but I really don't want it to live in Roland's
home directory, either.  If he meets up with a bus, the ksh93 project
needs to be able to continue.

If the ATT deliverable can't go into ON, and a stripped-down-for-ON
version can't be kept in sync with the ATT deliveries, we have a
problem.  If neither is acceptable, what other solutions are there?
In the past, several people suggested that ksh93 deliver via the SFW
consolidation, but the project team chose otherwise.  Maybe it is
time to reevaluate that suggestion.  The alternative of restructuring
ON and inventing a different nightly build system sounds like a
non-starter :-)

    -John


Reply via email to