Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline]

[Tom Lord]

    > From: Jan Hudec <address@hidden>

    > 1) The current gcc approach, as I understood it, is, that before
    >    commit, each developer runs a test. If it then breaks because
    >    someone else commited a conflicting patch, it is resolved
    >    ex-post. So without the tests, arch-pqm would perform exactly
    >    as cvs does now.

Right.

    > 2) A star of patch-queues. Since pqm can do star-merge, it would be
    >    possible to have several testing pqm-based branches. Merge requests
    >    first go there, are tested, and if they work, get merged into the
    >    mainline and tested as a bunch. The individual testing queues should
    >    be probably grouped by subsytems or features to be most useful.

Sure, that could sorta work.

I'd be worried that committers will be frustrated by the lag time
between when the commit and when what they've committed appears in
mainline.  For example, it would mean I couldn't say to you, on the
phone from far away, "Oh, I have something for that that's been
tested.  Lemme go ahead and check it in and then call you back in 15
mintues after you check it out."  Instead it would be "Oh I have
something for that .... I'll check it in and call you back tomorrow
after archive-side testing completes."

I think it's a rare thing when you can (on a large project) really
limit the commit rate for an entire project to be the maximum rate
that a single entity (such as a PQM) can run full tests between every
two commits.  Limiting the commit rate of individual hackers by the
rate at which they can individually test their own changes is more
common, especially if (as in GCC) the option of running "lighter"
tests for simple changes exists.

In a life-critical project, sure -- a Go Slow process is mandatory.
But those are (or should be :-) rare.

-t