|
From: | Aaron Bentley |
Subject: | Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline] |
Date: | Wed, 23 Jun 2004 01:50:28 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 |
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 1I 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.
[Prev in Thread] | Current Thread | [Next in Thread] |