gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline]
Date: Wed, 23 Jun 2004 02:39:09 +0100
User-agent: Mutt/1.5.6+20040523i

On Tue, Jun 22, 2004 at 09:20:31PM -0400, Colin Walters 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.

Lack of a useful hook.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]