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: libsanitizer merge from upstream r208536


On May 27, 2014, at 11:16 AM, Konstantin Serebryany <konstantin.s.serebryany@gmail.com> wrote:
> On Tue, May 27, 2014 at 9:53 PM, Mike Stump <mikestump@comcast.net> wrote:
>> 
>> On May 26, 2014, at 10:13 PM, Konstantin Serebryany <konstantin.s.serebryany@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.

I appreciate that.  I also appreciate that if all bugs in a checkin can be pointed out in 2 minutes, that is very nice indeed.  All I can say is, we welcome your contribution to make that happen…  but, despite that, it is generally impolite to put in bugs and say let’s remove the port that exposes the bug.  If you can do no better, then at least ignore it, this is more polite.  There will always be bugs, and you will always put some in.  Life goes on.

> If we learn about breakage months later when design is finalized,

Software is never finalized, neither are designs.

> changing the design is much more work.

Yes, software is hard.  :-)  Just wait til you try and solve a problem that autoconf was design to solve, then you will hard truly turned to the dark side.

> Finally, there is a psychological aspect -- I get sad when I learn
> that I broke someone's code

Don’t be sad.  Treat them as you would a slow running build bot.  Try and make them green.  :-)

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