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

[Colin Walters]

On Wed, 2004-06-23 at 02:16 +0100, Andrew Suffield wrote:
> On Tue, Jun 22, 2004 at 08:55:29PM -0400, Colin Walters wrote:
> > On Tue, 2004-06-22 at 19:11 +0100, Andrew Suffield wrote:
> > > On Tue, Jun 22, 2004 at 11:19:14AM -0400, Colin Walters wrote:
> > > > On Tue, 2004-06-22 at 13:20 +0100, Andrew Suffield wrote:
> > > > > Huh, interesting timing. I've been thinking about this problem for a
> > > > > week or two, and started to put together some of the intrastructure it
> > > > > needs.
> > > > > 
> > > > > Certainly gcc is a good example of a project which this problem, but
> > > > > I'm not convinced their approach is the best solution. A PQM-driven
> > > > > mainline that only allows commits which do not cause regressions is
> > > > > probably what they really want. But it's easy enough to handle what
> > > > > they currently do.
> > > > 
> > > > Isn't that exactly what arch-pqm can do right now?
> > > 
> > > Only if you have a magic "Should I merge this?" function.
> > 
> > Of course not, but it allows for enforcing arbitrary user-defined
> > precommit conditions, i.e., "Does this merge pass the test suite".
> 
> Yes, but this is based on the assumption that you have a sensible way
> to implement this condition. Which you actually probably don't.

What is not sensible about the current implementation?  

We iterate over the pending merge requests, try the merge in a temporary
directory, then if that has no textual conflict, run the precommit hook.
If that succeeds, then commit.

signature.asc
Description: This is a digitally signed message part