[Gnu-arch-users] Re: Why PQMs count

[Tom Lord]

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

    > Here's a wild-ass idea for you: just as with build systems, an SCM
    > should have a notion of dependency, and _that_ dependency forest might
    > be a "natural" notion of "whole tree" which should be up-to-date
    > before a commit.  This might or might not be the same as build
    > dependencies.  I can see arguments for stronger and weaker, and for
    > putting the dependencies under (partial) control of the
    > maintainers.

That sounds like an interesting idea or more like a family of
interesting ideas..... the idea of using dependency information to
guide revctl semantics.   Definately something to think about.


    > And you might even want to add features allowing searching for build
    > products to inventory and tree-lint.  Then they could (optionally)
    > check that the sources build, the tests were run, whatever.
    > Implementation will be hairy, I think, but conceptually well within
    > what tla's framework is already capable of, no?

I'm sure that "built-in" to core Arch isn't the right way to do that.
Hooks are _part_ of the right way.   But yes, Aegis-like higher-level
functionality is a promising line of future development for extensions
to Arch.



    >     Tom> Read literally, the [gcc] policy _is_:

    >     Tom>  "Don't commit without testing."

    >     Tom> Reading Mark's message in isolation, the policy apparently
    >     Tom> (to the casual reader) _means_:

    >     Tom>  "Don't make a breakage-inducing commit."

    > OK, I see where you're going now, but you can state the problem under
    > the literal policy, can't you?  The real question is "must you test on
    > the HEAD that you are proposing to commit to, or is a test on your
    > freshly updated workspace good enough?", right?

I think so, if I understand you correctly.

CVS in all cases and any high-commit-rate version with any revctl
system have the following annoying property:

        By the time you have a tree you want to commit,
        a tree you've modified and tested for example, 
        it is too late: you're tree is out of date.

So, the _only_ way to make a commit is to say "here are the changes"
and trust the system to apply them to the fast-moving version and fail
(arch) or partially fail (CVS) if the changes would conflict (arch) or
are to files within the tree such that your copies of those specific
files aren't up-to-date.   Short of a freeze period, nobody reliably
determines the contents of the mainline at any point in time.   They
just all through changes at it the revctl system serializes those,
throwing back any that it can't serialize because of conflicts (arch)
or file-up-to-date policy (cvs).


    >     Tom> So, in one sense, it's all a big sham.  The policy is a joke.

    > Only if you take the "no breakage in HEAD" interpretation,
    > rather than the literal "must test before commit" one.

Right.

    > But suppose you take an Einsteinian perspective, one which says
    > "simultaneous" has no meaning.  Then, OK, when your patch hits the
    > repository can be ordered with respect to mine in the repository's
    > time-line, but who committed first?  Einstein says that question may
    > not have an objective answer, since your timeline and mine may run at
    > different rates, from each other and from the repository.

No, Einstein says that that question _does_ have an objective answer.
In relativistic terms, the archive itself is a world-line and a commit
is a signal arriving from some remote event and intersecting that
world-line.  Relativity says that two events can intersect _two_
_different_ worldlines in both orders (observers can disagree about
the subjective ordering in time of the events) -- but it also says
that all observers agree about the order in which two signals reach a
single specific world-line.

So, if you fly past the planet at an outrageous speed, you may report
seeing Alice hit return after `tla commit' before Babs did, and I
might report the opposite, but we'll both agree about which revision
name was assigned to Alice's and which to Babs'.  We'll both agree
about what order the archive itself saw.


    > _I think this is a good allegory for the problem at hand._ And
    > it points to the "no-breakage" interpretation as untenable, but
    > "must test" is still viable AFAICS.  Operationally, when you
    > decide to commit, you must update your tree.  Then you must
    > build and test.  Then according to policy you may commit, even
    > if for relativistic reasons a "later" patch gets committed
    > first.

Right.  As an allegory rather than an analogy, it makes for a good
mnemonic about what the issue is.


    >     Tom> I.e., it's just "dog pile on the mainline" and fix what's
    >     Tom> noticed as broken later rather than "Form an orderly line and
    >     Tom> make your proven-acceptable mainline changes one at a time.
    >     Tom> No shoving and no smoking, please."

    > Sure, but there are social reasons why most projects have a dog pile
    > at least some of the time.  Is the PQM etc part of the answer for
    > those projects, or is it "just" a technical improvement in Arch that
    > allows continuous commits (since they're always pulls by the PQM
    > managing a branch that is by definition up-to-date)?

If the dog pile is large enough -- i.e., if the commit rate is
sufficiently high -- then a PQM really is part of the answer.

Arch won't let you commit directly if your tree is out-of-date.
If trees are out-of-date as soon or sooner than you can check them
out, absent a PQM, it would be impossible to commit.   (The conclusion
here isn't the absurd "commits are impossible on high-commit-rate
trees" but, rather, that the direct commit-rate is bound by the 
achievable update rate.)

A PQM removes that upper bound on the commit rate, or more precisely,
manages the upper bound very well by maximizing the achievable update
rate (since the update rate achievable by the PQM itself is the only
limit).

That works out much nicer than CVS and here's why:

In CVS, when a multi-file commit can't complete because _some_ files
are out of date, others can commit: the changes being commited are
therefore split into separate commits with other changes in between.
That interacts poorly with, to name one illustrative example,
mirroring the GCC CVS archive: an ill-timed mirroring operation can
leave you with a nonsense tree that contains some number of
"half-committed" changes.   Even when a CVS multi-file commit is able
to complete, you can _still_ wind up with interleved changes from a
concurrent commit.   The changeset nature of changes is just lost.

With Arch plus a PQM, of course, in spite of having such a high commit
rate that essentially all commits are from out-of-date trees,
neverthless, each commit either produces a single, atomic changeset or
fails due to conflicts.

Arch+PQM is also nicer than CVS in this regard because, whereas CVS
won't let you commit if any files you've changed have changed in the
repository, Arch+PQM relaxes that constraints and will only forbid a
commit if the changes would actually conflict with changes already
made.


    >     Tom> It wouldn't have been right for Mark post to say "Oh,
    >     Tom> somebody broke mainline."  (And that's not what he did.)  It
    >     Tom> _was_ right for Mark to say "Somebody broke mainline and
    >     Tom> timed out on fixing it.  Geeze, it's been two months!"

    > In other words, the breakage had become deliberate some weeks ago.
    > This is a social issue, and I don't see any technical solution.  

Right.  There's no solution there because there's no problem.   The
mainline (during non-freeze periods) is expected to break from time to
time like that because that way it can evolve more rapidly.   We don't
normally notice that this is going on and tend to have a simplified
mental model that the mainline is a succession of changes in an
intentional order because, given the modularity of GCC, that's a good
approximation.   But then there's a minor dust-up like this one and
you can see clearly how the mainline is being used.


    > In fact, this kind of behavior is eventually going to screw
    > other developers badly.  Sure, we have to accept a certain
    > amount of breakage for probabilistic, SCM non-atomicity,
    > reasons, but the more probabilistic breakage there is, the less
    > acceptable deliberate shirking becomes, AFAICS.

I have no idea whether the current GCC breakage counts as "shirking"
or not but, yes, the overall team spirit of GCC seems to be make
unbreaking mainline breakage a very high priority.

    > I really don't see how a PQM can help relax that; 

Just the opposite.   _Without_ a PQM you can't get into that bind:
arch won't let you.   If you _want_ those problems, because the
trade-offs make sense for your project, you'll need a PQM if you're
going to use Arch.


    > it's simply not acceptable for one person to break the branch
    > that everybody is working on merely because he doesn't have a
    > good fix yet.  On the other hand the PQM cannot deal with
    > "relativistic time contraction" on the one hand, and the social
    > issues on the other, to decide that the already committed patch
    > is lower priority and should be reverted in favor of one more
    > recently submitted to the queue.

I think that once you have a system that is tolerant of the
"relativistic time contraction" issue it is inevitable that people
will take advantage of that to say things like "Oh, this can be broken
for a little while."  

Again, I have no comment or opinion, even, about the current breakage
and whether it's just an extreme example of "business as usual" or
whether someone has really done something they ought not to.



    >     Tom> Any such program has good changes being produced for it,
    >     Tom> around the "world" (literally the world, in GCC's case)
    >     Tom> around the clock.

    >     Tom> The rate of change, viewed as an irreducible natural fact, is
    >     Tom> greater than any human maintainer can keep up with.

    > s/any human maintainer can/the project maintainer wants to/.  It seems
    > to me that the technologies you're talking about may often be
    > appropriate as an optimization of another feasible process, rather
    > than useful only when it is the only feasible process (which you are
    > arguing is the case for "projects bigger than GCC", I think).

I agree with that.


    >     Tom> In some sense, ahem, you could say that Arch (sans a PQM) is
    >     Tom> outrageously _backwards_.  Absent a PQM, Arch, in its move
    >     Tom> towards "whole tree orientation", takes the "C" out of "CVS".
    >     Tom> You can't commit unless you are up-to-date.

    > Commits are impossible _to the distinguished branch_.  It's plausible
    > that real projects need some "mainline" that is the consensus branch
    > for the next release, but it's not proved that I can see.  You could,
    > for example, take the Apache or Python processes as tentative
    > implementations of a process where individuals decide what the next
    > release should look like in terms of features, and then the developers
    > pick one of those integration branches, freeze, and fix all the bugs
    > in it.  In that model, the blockage you talk about is no problem,
    > because all the candidate branches are always up to date as measured
    > by themselves.

That's interesting.  I haven't studied Apache or Python process in any
real depth.   You're saying that they produce multiple "mainline
candidates" by cherry-picking from a pool of patches and then
periodically vote/pick one of those mainlines to promote to a release?   

If so, that's neat.

Yes, of course Arch can do that in spades and yes, commit-rate issues
are far less likely to show up with that technique. 

One thing that concerns me about that technique is "What do people
make changes _against_ if there are competing mainlines?"  But then,
if releases are frequent relative to the rate of contribution, perhaps
the answer is just "against the previous release, usually".

    >     Tom> Oh, sure, we took from CVS the idea that you don't have to
    >     Tom> "lock" a file before you modify it --- but we won't let you
    >     Tom> commit that file (absent a PQM) unless not only that file but
    >     Tom> you _entire_tree_ is up-to-date.  Geeze, even SVN doesn't
    >     Tom> impose _that_ limitation.

    > But "tla commit --files" is Wrong, because it leaves an automatable
    > consistency check up to the programmer.  Granted, whole-tree
    > orientation for the whole GCC project is an Emersonian hobgoblin of
    > elephantine proportions, but on the other hand an SCM that allows you
    > to change a macro definition in module.h and commit that without
    > testing or checking up-to-date-ness of module.c is missing something.
    > Isn't it?

Yes and no.  You certainly want your tool to be _able_ to prevent such
actions but there will always be a cost to that.  Sometimes it's
easier just to risk making a mess first and clean it up later if need
be rather than taking pains to never, ever, make a mess.

    > 
    > -- 
    > Institute of Policy and Planning Sciences     
http://turnbull.sk.tsukuba.ac.jp
    > University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 
JAPAN
    >                Ask not how you can "do" free software business;
    >           
    > 
    > 



-t