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

[Charles Duffy]

I'm going off on a little bit of a tangent here, discussing what my
workplace is trying to do. I think that at least one part of it should
be applicable to usage with gcc.

On Tue, 2004-06-22 at 23:55, James Blackwell wrote:
> Yes, if its "merge a patch, make test, commit the patch"
> 
> No, if its "merge a bunch of patches, make test on the whole lot, commit"

I've designed a new process for my employer looking (on paper) something
like the following:

Each developer has their own archive. They have multiple branches there,
commit directly to it at-will, etc.

There's an integrated branch controlled by a PQM. The developers have a
CLI (and maybe later GUI) tool that enables them to tell the PQM they
want it to merge a specific set of patches -- the usual level of
conflation happens here. Our automated test suite is run by the PQM and
can prevent a merge request from succeeding. (This is something of an
extension on Colin's PQM as it needs to be aware of the multiple
components in our product, and has some extra work assigned as well --
such as caching precompiled binaries from the last succesfully tested
revision of each library component). The PQM maintains a branch 
containing configs specifying which components have been tested
together.

Every so often (say daily), QA pulls the revisions specified by this
config, runs the resulting tree through manual testing  (as some aspects
of our software are very hard to automate testing for) and, if it DTRT, 
tags the revision containing that config into their tree. If it
*doesn't* pass their tests, they look through the list of changes
committed and either interrogate developers or try reverting changes
until they find the culprit.

Finally, there's a release-manager-maintained branch that tags off of
QA's manually-approved branch, with basically the same procedure less
the testing.

(This is how *I* spec'd it out. How the revision control guy we hired is
implementing it... well, that may be a different story).



The thing that might be reusable here is that there's cheap testing and
expensive testing going on at different times, and that there's an easy
operation (pulling and building a config) a user can do that says "give
me the latest version that's been through the expensive testing".

In the case of gcc, the cheap testing may be merely "does it compile"
(to make sure that the slushed-together patches don't produce severe
breakage), or it may not be feasible at all. However, gcc still could
adopt the expensive-testing operation that follows behind and provides
an address from which someone can grab a known-good tree (not to mention
harassing people when breakage occurs, another Good Thing).

Having the new first-level-integrated tree states not being merged into
the testing-approved config might also be the sort of thing to provide
just that extra bit of motivation (ie. shame) to prevent a developer
from letting their patch break the tree for a substantial period.