On Thu, Mar 10, 2011 at 10:28 AM, James Westby james.westby@canonical.com wrote:
On Thu, 10 Mar 2011 09:56:27 +1300, Michael Hope michael.hope@linaro.org wrote:
We currently use a feature branch / merge request / merge / test / push approach in gcc-linaro. This works fine for a reasonable cost but can mean that patches sit unreviewed and unmerged for up to a month. Ramana, Andrew, and I had a talk about this earlier in the week and I've written up the ideas here: https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts
Hi Michael,
One thing that isn't clear to me from that page is why patches can go unreviewed for days. Do you tie the review to the testing somehow?
It's the way things are. Andrew has been doing all of the review and doing it as part of the integration phase. This will change.
The proposal to have a designated person who will review patches promptly is one that has seen success in other projects. It trades off prompt reviews for more interuptions in someone's time, but it seems like that is often worth doing.
Some further questions:
* How frequently do problems get through review that are found by the test suite?
Ideally the test suite should have been run before the review and have shown no regressions. That's how upstream does it. GCC is complicated so a review will miss subtle things.
* How frequently do problems get past the testsuite?
Being pessamistic, say every second patch causes a failure found in the field not found in the testsuite.
* Would you be confident in your ability to have quality releases if there wasn't a testsuite run of each change before it lands in trunk?
Not a quality release, no, but I have good confidence in the patches in general. It's unlikely that a commit would break trunk.
-- Michael