[Gnu-arch-users] Re: project hosts, also "truenames" (was RFC:...)

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>
    >     >> Go back to the original problem.  You have a SourceForge-like
    >     >> archive

    >     Tom> Hmmm.  Other structures are certainly both possible and
    >     Tom> preferable.

    > Uh-huh.  savannah.gnu.org, for example?  [ritual burning of the
    > strawman elided]

Did I say anything about savannah?  No.  It's essentially the same
structure as sourceforge.

I am (vaguely, at this point) thinking more of extending the "library"
analogy.  Perhaps...:

* decompose the functionality of project hosts

  Part of what today's project hosts do is to provide cataloging
  (e.g., managing a namespace for projects; providing search functions
  and browsing functions).

  Part of what they do is to provide an acquisitions policy (e.g., 
  all projects on Savannah are free software projects;   SourceForge
  (as I recall) implements a different acquisitions policy).

  Part of what they do is provide provisioning for project hosting
  (e.g., revision control services, mailing lists, bug tracking).

  Part of what they do is provide distribution (e.g.,
  signature-verified tar bundles on Savannah).

  Those four areas can be treated as distinct (yet integrated).  They
  don't have to be a monolith.  FreshMeat is an example of factoring
  cataloging away from project hosting.


* make the provisioning component portable and peer-to-peer mirrorable

  That is, it should be possible for anyone to put up a project-host
  provisioning server that "joins the network" of such servers; it
  should be possible to non-disruptively migrate projects from one
  host to another; it should be possible to mirror projects between
  project hosts.  (A hard problem is what to do with mailing list
  names in this context -- but then perhaps the underlying mechanism
  should be usenet with email serving just as a convenient gateway to
  that.  Another hard problem is distributed bug tracking but that can
  be solved by an email-drivable bug database resting on top of a
  usenet backbone.)

  To make an analogy to the book industry, you could think of this
  style of project-host provisioning service as the printer and
  distributor -- the mirrors and usenet feeds as the books.  The
  separate cataloging and acquisitions policies define libraries, of
  which there can be more than one having divergent policies.


* standardize the cataloging format; add p2p and clearinghouse
  functionality.   Do the same for signed distributions.

  In other words (and no doubt some existing services provide
  part of this already) make an exchange format for "bibliographic"
  project records and mechanisms for for exchanging them between
  software catalogs.

  For example:  when something changes about the location of tla
  or when a new release is made, I now have several different 
  sites to update -- FM, Savannah, various web pages ....

  It Would Be Nice just to edit the record once and have it propogate
  to the various sites.  (In real world libraries, techniques like
  this are used to keep cataloging costs low, to implement a
  distributed review of new records for accuracy, and to create a 
  pretty good degree of standardization of catalogging practices.)


So, then, what would become of something like Savannah?

First -- cataloging would be independent of hosting.   Savannah could
catalog a larger number of free software projects than GNU can afford
to host and a larger set of projects than those who want to be
provisioned on GNU servers.

Second, project-host provisioning could become distributed and
redundant.  That is, people could expand the effective capacity of,
for example, Savannah by putting a spare box on the net that runs a
provisioning server (rather than having to go through the process of
donating or loaning the box to the FSF).  With a little mirroring, the
inherent flakiness of such an arrangement can be reduced to the point
where it would probably be more reliable than the centralized-server
approach.   

Vendors could even get in the act to put a few stable servers on the
net.   Since, in this system, project-host provisioning and
cataloging are separate, vendors could establish their own policies of
what projects to host -- it would be at the cataloging and
acquisitions layers of savannah, not at the provisioning layer, that
policies such as Savannah's "must be a free software project" would
take effect.

Third: There could be more than one catalog, with catalogs
overlapping.   E.g., a hypothetical savnnah.gnu.org,
savannah.gnu-europe.org, savannah.gnu-india.org etc. would all be
equivalent peers -- perhaps sharing "bibligraphic" records, perhaps
having divergent policies about what goes in the collection.




--------------------------------

    > ["true names"]

`tla tag' creates a log message that lists all of the patch logs in
the newly created revision.   It does that by searching backwards a
little ways in the ancestry of the project, summarizing the logs along
the way.   It does that to optimize access to the listing of project
logs -- a listing that's important to merging and several
merging-related operations.

It sounds like you want to expand the scope of that summary so that
the most recent log header in the ancestry of the form:

        X-true-category: foo

is copied to the new log message.

But then why should _that_ header be special?  And why _that_ rule of
"most recent instance supercedes"?  Isn't this at the top of a
slippery slope at the bottom of which are dozens of new header fields,
each treated specially (and differently from some of the others) by
commands like `tag', `commit', and so forth?

Normally I would say that an `X-true-category' header has nothing to
do with any of arch's jobs -- it has no use in merging for example.
The right answer is therefore to point out that you can add such
headers and manage them yourself, using only the existing features of
tla.   The only real question is whether you can obtain cooperation
from people to use the headers in the manner you advocate -- a social
problem, not a technological one.

In this case, though, to complicate matters -- you meantioned a use
_related_ to merging: you wanted to have it impose a kind of soft
firewall between GNU and X Emacs so that merges between them (at least
in some directions, depending on which subproject) would raise red
flags (because of the legal issues between these sources).

But that's a whole can of worms for any number of reasons.  It's a
mechanism that could easily (even accidently) be circumvented -- so
_trusting_ it for anything outside of a relatively controlled
environment would be foolish.  It's a mechanism that might make some
sense for the specific relation between the Emacsen -- but what am I
supposed to do when a week later somebody says "Well, I want something
sort of like that but the rules about what can be merged where are
slightly more complicated.  Surely you don't mind one more little
feature there, do you?"  Etc.

It seems to me that there's mechanism enough in tla already to try out
ideas such as yours and that nothing new is needed in tla itself.  The
smaller obstacle is a little bit of new scripting to manage new log
headers and so forth.  The larger obstacle is persuading people to use
the new headers -- a social problem.

One way to solve such a social problem might be to persuade me that
this is a killer feature -- a "must have" for tla.  If it shows up in
a first-class way in my distributions and documentation, then you can
just point to that and tell people that's what they're supposed to be
using.

But absent making a far more compelling case for the "true names"
feature, that solution isn't available to you: you can accomplish the
technnical goal well without new mechanism; if added as a core
feature, the new mechanism sits at the top of a slippery slope; the
new mechanism wouldn't expand arch's strengths in the areas of its
core competency but would begin to dilute the definition of arch's
focus.


    > From: "Stephen J. Turnbull" <address@hidden>

    > >>>>> "Tom" == Tom Lord <address@hidden> writes:

    >     Tom> That's mostly a social problem, not a technological one.
    >     Tom> I've made sufficient tools.  "Cooperate or die," so to speak.

    > No room for independents in your world-view, I gather.

I don't follow your reasoning.

    > Maybe I should just erase my freshly-minted Ancient Arch Archive.
    > Would that be a _social_ problem, or a problem of my _anti-social_
    > attitude?

    > Evidently, you're forced to put your vote on the former.

I don't follow your reasoning.


-t