Whole tree up to date before committing
ian.clatworthy at canonical.com
Fri Oct 23 01:39:00 BST 2009
Óscar Fuentes wrote:
> If my understanding is right, there is one PQM and all patches must go
> through it. This creates a bottleneck of its own. For the project I'm
> thinking on, even a 16 way machine would be unable to keep pace with the
> patches at peak hours, and that would check just one platform.
> So I don't see this as a big improvement for a highly active project.
Thanks for your input. Of the 100s of sentences in that document, I must
confess it wasn't the one you highlighted that I expected readers to
have an intense debate about. :-) It's certainly an important topic though.
As others have said, active projects have several choices:
1. Make a change. Run local tests. Commit. If the commit fails because
the tree is out of date, the developer can make a judgement call as
to how important it is to run the tests again before re-trying
the commit. In my experience, Bazaar will fetch the latest tip
pretty quickly and there are rarely conflicts, so that isn't a
bottleneck unless the commit frequency is over 20-30/hour[*], say.
Most developers also know their code base well enough to know whether
another change could impact theirs or not. People are human though so
the buildbot remains an important component of any serious QA effort.
In fact, the higher the commit frequency, the greater the risk of
instability so discipline and automated testing only increase in
2. Move to an automated gatekeeper. As you point out, this is no longer
the centralized workflow.
FWIW, I frequently mix-and-match centralised and distributed workflows.
On 90% of my projects on Launchpad, my trunk is a bound branch and I
make small bug fixes directly there. For new features or complex bugs,
I'll create a feature branch, work there and merge back into trunk when
it's ready. I find this work pattern really productive myself.
> Sorry if I missed something essential, but I was unable to find further
> documentation from that web page.
PQM is an awesome tool but it's documentation is limited from all
accounts. That's a real shame but one *I* don't have the time/expertise
to address right now. FWIW, our PlugIns page also lists "testrunner"
under Change Control. This may be of interest to some folks as well:
https://launchpad.net/bzr-testrunner. (Neil is best placed to comment on
[*] I believe your team is making 100 commits per day and many of them
are small. I wonder how many of those would become commits on a feature
branch if larger items (both features and bugs) were developed that way?
More information about the bazaar