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

[Aaron Bentley]

James Blackwell wrote:

> When I take tla-contrib patches from Bentley, I don't pull and commit
> his patches one at a time. I take all of his current patches, apply them
> all at once, and review them as one combined product, and then commit.
> If I were running a test, I would be testing his patches as a group.

I've been thinking along those lines, too.  You can guarantee that your 
queue never gets backed up by testing, if you do:

1. merge all pending patches
2. test.
3. if test succeeded, goto 1
4. Do detailed testing to find the exact cause of the problem.
5. reject the problematic patch(es)
6. goto 1

I don't know if anyone's considered this yet, but it seems to me that if 
you're doing out-of-date commits, you're doing some form of commit --base.

Instead of an email-based PQM, you could just have a PQM with a deposit 
branch*.  Everyone can do
"tla commit --out-of-date-ok --base $(tla logs -f foo--mainline--4.5 
|tail -n 1) foo--deposit--4.5"

Since we haven't implemented any safety checks on replay, the PQM can 
just do "tla replay foo--deposit--4.5", to apply all pending patches.

What does that buy us?  Maybe not a lot.  Clear sequence: unlike with 
email, the commits happen in a clearly-defined order.  Also, there's no 
risk of losing a depositted commit, even if all traces of the 
committer's archive are destroyed-- only foo--mainline--4.5 and 
foo--deposit--4.5 are needed to reconstruct anything that's been 
committed.  Rejecting a patch is quite easy-- just sync-tree.

On the downside, it does require a publically-committable branch.

Aaron

--
*Notice how I'm not calling it a "submission branch", to avoid confusion.