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

[Jan Hudec]

On Wed, Jun 23, 2004 at 02:39:09 +0100, Andrew Suffield wrote:
> 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.

As I understand, GCC in fact uses none and really needs none. They have
policy of testing before commit. Things can still break when two people
commit conflicting changes, which is fixed ex-post.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature