From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 2B4B138618DC for ; Sun, 27 Jun 2021 21:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B4B138618DC Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-377-Osh1xExNMSamdt6AbJxppw-1; Sun, 27 Jun 2021 17:52:59 -0400 X-MC-Unique: Osh1xExNMSamdt6AbJxppw-1 Received: by mail-qv1-f70.google.com with SMTP id z6-20020a0cfec60000b0290263740e5b2aso15992475qvs.6 for ; Sun, 27 Jun 2021 14:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MWLMELx66tyLpXk4Pn2pP4/6korkbt0K2ZqYzS7uM/Q=; b=GLDwH6W4n8oB3kZOWE+2+DYmG2IcpnmEwWCgQjGuZYWTZkKINftBayL7QEyTFF03o8 GrAIkz8a6wMmWJIuwrW8Z1gnmvsojHXRbHSd2TBRvr9u/nNkhA5G4sINtbw3Ju/nDeLB KcxmKhKdJeXenTJJlwwXboFEqxLWDtKI7ZP/Ai+EvGorGfuK3JDKyDUHa2TTo2xVhc4j sNnChG8f1dF0AqUQJGsNA6M/Bf3oHniOXjEqTDULh3XRp1+yt6edQNFbJV1tBv3rZNva Dp6miu5VYIVywgSluCDpcxtVNLAa53xcAZCbiyIGaNy2JiskQ4dPQZhqKZLM64GOzLJp p8Iw== X-Gm-Message-State: AOAM5316sZwT4+5RC/bNzs5iNkKv9YSt1VRcCbXErLyao2iwKYQuc7s/ lSduBIe7wwH1SewO8KEdPgAXB3sIdDVI7D9fYAYOaI7d6/hptTgmnDOTnEmebS38WX40zkCWrOP IdMfW/QG2cRXLF4XQSMsV//K1Hwhgd3/gVV98Z41EKdo87Oodznz7owCcEPP6pM6W3bzWSQ== X-Received: by 2002:a05:622a:1710:: with SMTP id h16mr19241883qtk.241.1624830778687; Sun, 27 Jun 2021 14:52:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRUdRuOMwTscUwv/SEvqw2iKUHuXddbcYOVHqMtXs/50Wpvc+gt0zK/z7F9Kk/E2kpObe4iA== X-Received: by 2002:a05:622a:1710:: with SMTP id h16mr19241873qtk.241.1624830778478; Sun, 27 Jun 2021 14:52:58 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id g5sm2148950qtj.7.2021.06.27.14.52.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Jun 2021 14:52:57 -0700 (PDT) Subject: Re: One test per line, one source per line, etc. etc. etc. To: Florian Weimer , Carlos O'Donell via Libc-alpha References: <875yxz12we.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Sun, 27 Jun 2021 17:52:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <875yxz12we.fsf@oldenburg.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 21:53:04 -0000 On 6/27/21 4:14 PM, Florian Weimer wrote: > * Carlos O'Donell via Libc-alpha: > >> Do we have consensus for someone to just cleanup all the makefiles >> to have one source per line, one test per line etc.? > > I think there was some opposition to trailing \ in lists in Makefiles. In this thread: https://sourceware.org/pipermail/libc-alpha/2020-December/120667.html There was no objection, but it was a concrete change, not the general discussion. Ah, this is the thread I proposed it: https://sourceware.org/pipermail/libc-alpha/2020-December/120693.html DJ was in favor. Joseph appears to favor LC_COLLATE=C. Siddhesh suggests tests could be renamed to get more logical orderings. Carlos clarifies, yes, LC_COLLATE=C, and yes test renaming would help. There doesn't seem to be any opposition. I think we have consensus to change all the files in a semi-automatic refactoring that would help reduce conflicts. > This: > > routines += \ > read \ > write \ This. To reduce conflicts. > > vs: > > routines += \ > read \ > write No objections noted for this that I can find. > >> The more reviews I do, the more this causes my to stumble and have >> to work through merge issues. >> >> If I want to get to 100 patches reviewed per day I think this is going >> to block me. > > Avoid merge conflicts also needs a custom merger (easier if the data is > in separate files with a more regular file). Avoiding *all* conflicts needs a custom merge driver. > Sorting the lists lexicographically avoids conflicts only > stochastically, for sufficiently long lists. And we have such lists already so the refactor would reduce conflicts without much actual work required. In summary: - I see no objections to a refactoring across libc to do this. - I see no objections to trailing \. The patches would obviously need to go through review, but it seems like all we need to do is do the work. -- Cheers, Carlos.