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: James Blackwell
Subject: Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline]
Date: Wed, 23 Jun 2004 00:55:56 -0400

From: Andrew Suffield <address@hidden>
>     > 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.
>

From:  Tom Lord <address@hidden>
> I thought about a PQM-driven Aegis-like protected mainline but I don't
> think it works out unless you do it in a _fairly_ hairy way.
>
> GCC commits happen too fast (last I checked) to serialize them while
> inserting tests between each one.
>
> I.e., just naively dropping a "make test" call into your PQM just
> before the "tla commit" --- probably the commit queue will grow
> without bound (until the developers notice and say, hey, this isn't
> working :-).

Yes and no.

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"

When I take tla-contrib patches from Bentley, I don't pull and commit
his patches one at a time. I take all of his current patches, apply them
all at once, and review them as one combined product, and then commit.
If I were running a test, I would be testing his patches as a group.

One committed changeset in arch is worth a whole lot more than one
commited patch in cvs.

I'm not incredibly familiar with the gcc's working strategy, but I'm
willing to bet that the development job has been broken down into areas
of expertise. Each mini-development-group will serve as a conflation
point for gcc development under arch.



-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400




reply via email to

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