Re: [Gnu-arch-users] Re: Conflicts in .arch-ids

[Tom Lord]

    > From: Catalin Marinas <address@hidden>

    > address@hidden (James Blackwell) writes:
    > > So I'll ask this... is there anybody that, if a licensed copy of
    > > bitkeeper were provided to them, has the time, the inclination
    > > and the credentials to work on a BK->Arch gateway?

    > You could ask this on the Linux kernel ML (but only after you setup a
    > filter for Larry McVoy's e-mails :-) ).

And I'll ask why anyone would seriously bother.

Kernel snapshots are frequent enough that a not-useless history can be
recovered from just those.

Doing more than that, trying to translate the BK database, only
accomplishes three (undesired) goals:

  1) It legitimizes BK and helps them to remain in the 
     business (even if its only a marketing business) of
     working with the kernel.    Gateways help BK to survive
     rather than encourage it to die.   If anyone should
     be writing a BK<->arch gateway, it's bitmover.

  2) It distracts people from the more useful task of improving
     native arch usage.

  3) It leads people down a primrose path to hell in which they set
     out to perform the impossible: to construct an isomrophism
     between arch and BK meta-data.  If the effort fails, the expected
     outcome, that's just a waste of time (what exactly is the return
     here?).  If the effort succeeds, then swell, Arch is de facto
     submissive towards BitMover because we have to
     hope/persuade/advocate for them to not change the BK meta-data
     formats.

I would say that the idea of gatewaying to BK is an expression of the
heuristic "Do as *much as possible* to make Arch work nicely for
BK-users, especially in the direction of migration."

A plausible-sounding heuristic but I think this one is more tactically
wise: "Do as *little as necessary* (but no less) to make Arch usage an
option for current BK users."

If that second heuristic actually works then, won't we seem ever so
clever for our athelete-style conservation of effort and energy?

So screw it, I say (as one not currently doing the kernel-host work
myself :-):  just import the snapshots and leave the steamy pile of BK
drying out on the sidewalk where we found it.   

Meanwhile, take that extra energy that would go to gatewaying and,
instead, just make the native arch environment for kernel work
incrementally better.    Write a micro-GUI to visualize some neat part
of arch history.    Or work on performance tuning if you have a modest
workstation.   Or set up a PQM for the kernel.   That sort of thing.

-t