This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] Fix bootstrap (PR rtl-opt/29879)


On Sun, 2006-11-19 at 21:10 -0800, Andrew Pinski wrote:

> I think what happened was Zdenek posted his patch on the 23rd of October
> and was not approved (and applied) until after fwprop was added.  And
> there was no retesting of the patch after Zdenek's patch was applied.

> Maybe a policy of two weeks old patches during stage1 (and maybe a month
> old in stage2/3) should be rested before applying them.  This should

I think a even a single day is enough. If I post a patch one day and
don't commit it until the next (or even later that day), I always either
do an update or fresh checkout/apply patch and build/make check to
ensure nothing has interacted with what I am applying. Good lord, I
think it is simply appalling to check in patches which are 2 weeks old
without testing them again.

For major check-ins, I usually do a fresh checkout and build/test cycle
afterwards to make sure nothing broke. (or make sure I didn't forget to
checkin a file, etc)

You cant reasonably remove the couple of hours window between applying
and building/testing/checking in, but it at least vastly improves the
chances of not causing problems. The person doing the check-in should
exercise due diligence to ensure they didn't introduce anything
catastrophic.


> Maybe instead a policy where checking patches cause the trunk to be
> frozen until it is tested on at least two targets and then applied.  And

I dont think freezing the branch in necessary. We can minimized that
hassles by simply attempting to minimize the time between our patch
applies and check-ins.

Andrew


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