[rfk-dev] git surgery or re-gitting

[Peter A. H. Peterson]

Quoting Eric S. Raymond:
> David Griffith <dgriffi at cs.csubak.edu>: 
> > Have we come to a conclusion as to what we're going to do regarding the 
> > git repo after Sourceforge?  I'll go ahead and put my Inform edition of 
> > rfk on Github for now and deprecate its direct inclusion.  Comments?
> 
> I don't know of any conclusion about the move, but I plan to knit
> the Inform releases into the history as previously requested.  It's
> next on my list after the current siege of work on reposurgeon.

I don't think an official decision was made about either. 

I still kinda like the idea long term of keeping everything at
rfk.org. But there's absolutely no hurry to do that, and it shouldn't
need to hold up our decision about how to structure the git repo(s). 

However, I think that separate, parallel git repos sourcing a
canonical NKI source is the best approach. For these reasons:

1. there's no (good) way to get just the part you're interested in if
all the repos are joined. It seems like bad form to make people
download Dreamcast or OpenGL code when they just want to look at the
Atari 2600 version... so i think One Big Repo is not the best
approach.

2. there's no (good) way to have a git repo refer to an external file
(i.e., the vanilla.nki) so that it would get cloned remotely along
with the port source (nested repos or some kind of "external git
dependency" or something). So there's no "automatic" way to make git
work transparently with separate repos.

3. I'm not that interested in fragile hacks that could possibly fix
one or both of the above objections. If there isn't a *good* way to do
it, I don't really want to do it. That would just be someone's
neckpain later.

So I think that my preference would be for every "port" to use a
mechanism for getting the current nki file, such as HTTP from rfk.org,
or by downloading it from sourceforge at build time or something along
those lines. Online versions could source the file from rfk.org at
runtime. 

The ports would also include their own code for massaging the nki file
into their internal format.

Current authors can keep whatever git host they currently use.

Either the vanilla.nki file could live in the POSIX repo, or it could
be in it's own dedicated repo and the POSIX port would source it just
like everybody else.

So, if people generally agree with this concept, it seems to me that
we should break the Inform port *out* of the POSIX repo, not fold it
in. The same goes for PalmOS but that hasn't been updated in about a
decade.

Thoughts?

Peter


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