On Tue, May 27, 2014 at 9:53 PM, Mike Stump <mikest...@comcast.net> wrote:
>
> On May 26, 2014, at 10:13 PM, Konstantin Serebryany 
> <konstantin.s.serebry...@gmail.com> wrote:
>>> On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
>>>> Because this is my default reply to any such case. :)
>>>
>>> I hope that is a humorous reply and not a serious one.
>>
>> Not really humorous. Our position is and always was
>
> We don’t expect a guarantee that you keep code working.  Only that when _you_ 
> break things that you try and help out as you can, and if you cannot, merely 
> to ask others for help.  Doesn’t seem to me to be an unreasonable position 
> and seems to have worked fairly well for the past 27 years.
>
> So, the right way to treat a regression that you hear about from the gcc 
> side, is exactly the same way you handle a green to red transition on a build 
> bot.
>
> So, let me ask, when you break a build bot, is your first response to want to 
> disable the port the regression is found with?  If not, then why treat the 
> regression found on the gcc side any different?

If a bot breaks, we know about it within tens of minutes.
The context is still fresh, fixing such failure is typically a matter
of minutes and costs us nothing.
Of course, the bot should be accompanied with a person who supports it
and can help us if we don't understand the failure.
I am extremely happy to see the FreeBSD build bot, which became green recently.
http://lab.llvm.org:8011/builders/sanitizer_x86_64-freeBSD9.2

If a problem is discovered 5 months after it has been introduced, the
cost for fixing it is much higher
as it involves more testing, more code reviews, etc.
Every time a platform owner sends us a patch here, we need to remind
that the patch has to be sent upstream,
and every second time we need to explain why.
Our code is unusual in many ways and we have to edit half of the
patches we receive.
We have our preferred way of sending patches which some of the
contributors tend to ignore
(I have strong opinions about the rules for sending patches in GCC,
but I keep these opinions to myself and try to follow the rules;
some of the GCC community members neglect to follow *our* rules).

Moreover, if we know that something breaks on a given platform, we may
change our design decision quickly.
If we learn about breakage months later when design is finalized,
changing the design is much more work.
I remember Jakub asked to redesign a part of code to make it more portable.
The idea was reasonable, but I would not even attempt it w/o having
bots for all supported platforms.

Finally, there is a psychological aspect -- I get sad when I learn
that I broke someone's code, even
when that someone is very polite (not all of someones are polite
though). I want to know about a breakage first -- feels better.

--kcc

Reply via email to