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 807B3385783F for ; Tue, 12 Jan 2021 02:52:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 807B3385783F Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-429-FA3N-1ofOLCLKbwJzPXSlg-1; Mon, 11 Jan 2021 21:52:42 -0500 X-MC-Unique: FA3N-1ofOLCLKbwJzPXSlg-1 Received: by mail-lf1-f70.google.com with SMTP id w11so391940lff.22 for ; Mon, 11 Jan 2021 18:52:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nGeLikPWLkAGRFb8CTvYxc9GuM2a9omz1Yg5gVa3FSI=; b=TPNmro+0UhwKc6x3ZqlQzGZVDWhaEokogs3k0KLZFzPhXlApWvBFKDEKn+/xCEHVJm HFuMuy1b6P9RQ1zwEYDJgBnJa8JgEUCix48OLBWmLlynOtZ0MC9O+5MAu8DTsVu2pK0y AMtY6cFgGYzFwjUGfACV1OBBhaxbQlPlBR8A2352O2IE4tvEFWXok4vPFwpzzlSx1RFh 16pgQtVnkVQSHgf1H5+UElWBCe9zx+irKO1nZh3im6DDd/B8WFeuLoMZ1mAi9oYxEmtb IZIw/ej8MEfePmVhvTNSJRvw76ZaQb5g2bPJ05Yrlq6M+B23NjHeVhJvUt3zBghfExJ5 UE5A== X-Gm-Message-State: AOAM533ewRjffMtw5SwTj57Y2DuzJcKgjEN/V9lgXHVEMjY/zkAY+VkH XoFFRqgEbKkwprPhTSmyPbCgb43HD712TuOY1fiG8YgE1iiXNHNiWhX6qRwd7zBvG4o5WuwpF/8 a1nq6pSGYKeuU3g/0Y9uMKtIItTtkVPoNLGQC X-Received: by 2002:a19:9d3:: with SMTP id 202mr1092941lfj.388.1610419961024; Mon, 11 Jan 2021 18:52:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdOPdgZ0svMxBBY3UE6qeExBm5lc335tybaeGOPxhW4mB7OmOgy2NC8MAKbisqNt70c6Y268gnO0Uuu+4MLLc= X-Received: by 2002:a19:9d3:: with SMTP id 202mr1092927lfj.388.1610419960847; Mon, 11 Jan 2021 18:52:40 -0800 (PST) MIME-Version: 1.0 References: <0db9d8a7-7359-8013-6b46-7fa1c24cd15c@redhat.com> In-Reply-To: From: Siddhesh Poyarekar Date: Tue, 12 Jan 2021 08:22:04 +0530 Message-ID: Subject: Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5) To: Adhemerval Zanella Cc: "Carlos O'Donell" , libc-alpha , "H.J. Lu" , Florian Weimer , paul zimmermann , Szabolcs Nagy , Arjun Shankar , Tulio Magno Quites Machado Filho X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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: Tue, 12 Jan 2021 02:52:47 -0000 On Tue, Jan 12, 2021 at 12:05 AM Adhemerval Zanella wrote: > Florian said he will check on this, but he wasn't sure it he will > finish in time. Both patches seems ok at first glance for me, > although Siddhesh has raised some concerns about the 2nd patch > loader change (and H.J.Lu noted that we did change the loader for > the hwcap isa work recently). Oh I did not have any specific concerns about the second patch because I had not even seen it :) What I said was that typically during freeze we limit non-bug-fix changes to those that don't have a major impact on architecture and distribution testing and that criteria may need to be applied to the second patch. It's your call to make as RM on whether to include it or not, not mine. > 2. ld.so: DSO sorting algorithm patch, both testing infrastructure and > new algorithm [3][4]: Florian is not sure if this change would be fully > reviewed for 2.33, so he is considering postponing to 2.34. It was this patch that I specifically stated was IMO unsuitable for inclusion during freeze since it would interfere with distro and architecture testing schedules, but again it's your call as RM. The more important point I made was to encourage review of the patch so that it is ready for inclusion the moment master opens again and doesn't get forgotten. In fact, I want to start a conversation on whether we should reconsider this aspect of the release freeze process. The freeze process made sense 7-8 years ago when we were a smaller contributor group and all of us would be focused on bug fixes and testing during that time and there was little scope of us being able to review new patches during that time. We are a significantly larger group now, so does it make sense to change the process to make the release branch at the freeze point and continue development on master? That way we potentially allow development to continue on the master branch while the release branch stabilizes. Tentatively, the freeze point would look like this: 1. RM calls freeze and asks everyone to stop commits to the repo 2. Make a release/2.x/master 3. Update VERSION to 2.x+1.9000 in master 4. Announce release branch on libc-alpha and reopen development >From this point on, development continues as normal on master. For inclusion in release/2.x/master, RM approval is necessary. Siddhesh