Re: [Gnu-arch-users] Nit

[Tom Lord]

    > From: Evan Powers <address@hidden>


    > To use Colin's patch queue manager as an example, suppose that GCC (or an 
even 
    > better example, the Linux kernel) starts using arch.  [...]

    > In such a situation that pqm might get beaten about pretty hard as every 
    > developer and his dog sends merge requests to the pqm. Having to 
fork/exec 
    > tla for every operation wouldn't help.

(It turns out, Colin and I were mostly in violent agreement -- it just
took us a while to realize that.   But about fork/exec costs....)

I doubt that the fork/exec costs will dominate in any huge way but it
doesn't matter if I'm right because I agree with you that, under heavy
load, pqm (or any smart-server functionality) has a good chance of
becoming a bottleneck.  The operations we're thinking about having
servers do here are pretty heavy no matter how they're implemented.

Worse than, say, just GCC or just the kernel: what about a "project
farm" like Savannah or SourceForge?   We've already seen both of those
projects suffer from both computing and administrative resources and
that's only going to get worse.

On the one hand, arch can help to relieve those services if we stick
to strictly dumb-server modes of operation.  

On the other hand, we can help to make the problem a lot worse: We
have lots of evidence that repository-side server power helps projects
run better (to name a few, View{Arch,CVS}, bkbits, the de facto
testing infrastructure of GCC, the plans people have been making for
pqm and similar tools....).

It's not a very arch-specific problem either:   I think it's a pretty
safe bet that svn does not consume _less_ server-side resources than
CVS other than, perhaps, network bandwidth (and that only for
committers and regular updaters and I wonder how much of a project
farm's load those groups are responsible for compared to people doing
one-time full checkouts or browsing operations).

So, yeah, I think the free software development world is drifting well
into a territory where its just stupidly underpowered with respect to 
"development server" resources.

Does it makes sense to hack like mad to get a factor of 3 improvement
out of something like pqm (by making libarch binding-safe, etc)?   I'm
not so sure -- I think the size of the server shortage is much larger
than that and, if really solved, tweakish little improvements to
server utilization might not be worth the cost.


    > Obviously this is not an argument against a CLI interface, and
    > in retrospect this isn't as strong an argument as I had
    > hoped. 

Ok, but I do think you're pointing towards one of the _real_
scalability problems.   It just happens to be a problem that I don't
think can be solved by tweaking any of the revision control systems:
it's a hardware/administration/server-side-hacker shortage.


    > But I think it at least demonstrates the probable
    > existence of a (not insignificant) problem space where
    > in-process is the better option. I think arch should offer both.

There's definately cost/value trade-offs in that problem space and 
implementing in C just makes those a lot sharper.    Maybe somebody
should write a Common Lisp or Java version of arch :-)

-t