From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 52CF238708B9 for ; Tue, 13 Oct 2020 17:05:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 52CF238708B9 Received: by mail-qt1-x82f.google.com with SMTP id h19so407397qtq.4 for ; Tue, 13 Oct 2020 10:05:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Jf1QMHptZWhQOrwW6AWWyskzuzxIzm9SKW4zQ8WBRa0=; b=talnv1LMpeMEnjyt4oEqO8rnwYNfl6Aq1vJOZ4nmEpUpgxu9fi1CJ5Hn+7ebxWj7HE trRwmEL+WgsfhXOflkXuqNae1b2gciqqBf4rYYvDrAwpJ38U/uFCeT6ktwcKAtrVEBYe hlSublFkC1Kt2XGYsKro4XSX7mVRAuZ/jldUXgXJavXUt6rSZKpx4JFZ6xSnRSyYubxh wxx0PlesSqivwDUbJgZiWvLHHMgjhPMIXRtaOlvOkA6oMSQdhIiMC452s63VyIoXanYy k59RB0k2IeUjtU3NGzSvVGU4IH+fKagXBBV0xBCP3pqsdVjmx9S3VNbtwCwFH6awOCyQ 9+cA== X-Gm-Message-State: AOAM533kCyQx9VX/scN2wnnQldbiniJJBxEXDxDuuPFkCUrKvaQwvUMi 3OMRgwm3dl2ZnRbrpcoZIRJoHlAjQP0mpA== X-Google-Smtp-Source: ABdhPJyWd2yk1et3Kg61Ufv9g/4PzBCJwxST6nnWO43n90v3vm/alFJAumqjPJtlxvKpu6fYsyD59Q== X-Received: by 2002:ac8:1923:: with SMTP id t32mr627806qtj.384.1602608709596; Tue, 13 Oct 2020 10:05:09 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:fe4b:20a4:d21:e79a:d7f0? ([2804:7f0:8283:fe4b:20a4:d21:e79a:d7f0]) by smtp.gmail.com with ESMTPSA id j24sm170264qkg.107.2020.10.13.10.05.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2020 10:05:09 -0700 (PDT) To: "gdb@sourceware.org" From: Luis Machado Subject: Regressions getting more common Message-ID: Date: Tue, 13 Oct 2020 14:05:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 17:05:11 -0000 Hi, I don't know about other non-x86 architectures, but over the past year I've been noticing more and more regressions being introduced, unnoticed, for ARM/AArch64. This is not good and causes a lot of pain if you have to keep tracking things manually, like we do now. The buildbots worked great for this very purpose, but Sergio has moved on to other duties (thanks for all the work!) and can't maintain it anymore. The builders are still there though, sitting mostly idle. We have a beefy ARM/AArch64 builder, which I can maintain for others to use. We can do better than to declare things OK after a single round of tests under x86, which has been the trend unfortunately. The subject of better CI has come up multiple times on IRC, with sad memories of the gerrit experiment's demise. Now we're left with review by e-mail and no broad testing. I think we need to discuss better validation pre-commit and possible CI solutions for GDB. It is pretty easy to exercise x86, but it doesn't sound fair to other architectures to have to keep cleaning up after things that have only been validated on that architecture. It would be great to establish a roadmap so we can get GDB's testing to today's standards, and maybe revisit the use of more modern patch review tools while at it. What do you think?