This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trunk frustration


kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     It's not fair to other contributors to simply commit your buggy
>     patches to the trunk and expect everyone else to clean up your mess.
>     It's just a way of forcing other people to do work that you couldn't
>     be bothered doing and that they'd rather not do either.
> 
> Obviously in the case of major development, that's right.  But I don't
> see the case we were talking about as being that major.  There are quite
> a lot of resources out there for testing and I do indeed feel that it's
> reasonable to distribute some of the testing load to the community at large.

I don't see that the size of the change necessarily has anything to do
with it.  Larger changes don't necessarily need more testing; the
testing requirement is determined by the need to ensure that the
change works.  A new port is "major development", but it needs only
minimal testing; yet a small change somewhere in the middle-end might
need to be tested on three or four targets if that's necessary to test
all the cases.

I agree that the community can supply lots of resources for testing.
However, it doesn't follow that it's OK to just appropriate community
resources for testing; the proper approach is to ask first.  One way
to do this is to place the changes on a branch and test them there
using "community resources"; another way is to post a patch and ask
individuals to test it.

> Jan's patches were incremental changes and I see a value in having
> available the resources of the community at large in the testing,
> especially where there aren't any problems expected.  That's the
> advantage of the incremental approach: you can take small steps, each
> of which you are quite confident of, and you'll find out if you were
> wrong.

I don't disagree with this approach.  It's just that I want people to
be confident because their patches have been tested carefully, not
confident because "it worked for me".

> Of course, this approach isn't reasonable, as you say, in the case a
> major development that isn't suited for the incremental approach.
> But if you can't use it in doing incremental changes, you lose much
> of the advantages of doing things incrementally and having a large
> development community.
> 
> I don't agree with the characterization of his patches as "buggy": yes, there
> was one (or perhaps two) with problems on some architectures, but the vast
> majority of them produced no problems at all.

I wasn't intending to refer to any particular individual in the above,
I was stating a general principle.

However, in the specific case, by my count there were eight patches so
far this month which caused regressions on either powerpc or i386, out
of 31 commits.

If only 10% of the 285 patches committed to gcc mainline so far this
month were broken enough to cause a regression, we would have
introduced 28 new regressions---more than one per day!  Because of the
high change rate of GCC we can't afford to have people commit patches
which they think are 'probably correct', or even '75% correct'.  We
need to aim for something on the order of 95% or 98%.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]