[rfk-dev] folding in NKIs from the inform edition

[Peter A. H. Peterson]

Quoting Eric S. Raymond:
> I have a slightly different concern.  I would like the ports to be 
> refactored so there is just one NKI file in the distribution that all
> of them use.  In some cases this might involve writing machinery to
> massage it into native string-array initializers.

I have a slightly different concern relating to your concern. 

Are you proposing to create a Grand Unified Source Tree of all the
"ports"?  With a build system to "build" any/all of the ports from the
single tree?

I can see how that could be a neat kind of performance art as well,
but I'm concerned that this could become a burden to maintenance. I
mean, if it ain't Baroque, don't fix it.

Certainly, if this is your idea, I think it's something we should all
have a long chat about before understaking.

In case you are thinking that (and forgive my overactive imagination
if you are not), here are my concerns in more detail:

The fact that there are a few ports in the old SF.net source tree is
an artifact that we abandoned a long time ago, since virtually the
only thing that any port share is the NKI list. In the past, any port
author could have written massagers, but by and large they didn't --
perhaps mostly because rfk ports tend to be quick and dirty, more
focused on functionality than compatibility, and in more than a few
cases because of platform constraints on length, etc. The ports
come in, they go up (eventually, whoops!) and they almost never
change. 

At first it seemed sad that the ports were orphaned from the POSIX
tree, but then it seemed like it was probably best because of the lack
of shared code.

But more than that, I don't think we should force port writers to use
the vanilla list, nor do I think we should force the consortium to
integrate port code into the repository if the authors do not care to
do so. I think that is a burden to authors likely resulting in fewer
successful "ports" and a burden on project members for integration.

I don't think that checking out the POSIX code should give you a huge
blart of all 30+ ports. Having a GUST (Grand Unified Source Tree) of
all the ports also probably makes the build system question a lot more
important, which is also to say kind of makes the build system a
bigger headache in the long run for POSIX maintainers. 

That said...

I would like to see source repos for all the ports, and I would very
much love to see massagers written for any/all the ports where it is
practical to do so and where the original authors agree and/or the
licensing permits this. I think these could be written on a piecemeal
basis by motivated contributors. Maybe there's a straightforward way
where the different repos (that have massagers) could pull from the
same NKI file without being all glued together. Maybe they could be
more loosely coupled, like having massagers and a pointer that says
"go here to get the latest vanilla NKI list!" That might be neat.

But I don't think the completeness of the overall project should be
dependent on this task being finished, which is also to say that I
don't think our choice should require any special kind of personpower
going forward. Historically, ports trickle in a few a year like babies
in picnic baskets, but the kind of flurry of activity we are seeing
now is a once-a-decade kind of thing. For better or for worse, our
modus operandi has evolved to suit sustainability... slow and steady
wins the race.

-- 
Peter A. H. Peterson
Graduate Student Researcher
Laboratory for Advanced Systems Research
University of California, Los Angeles