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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 4EB743858C50 for ; Wed, 5 Apr 2023 06:31:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4EB743858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680676307; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bYasjCShlWnYkNfJ22FS01BpuKfQldqOdM+Iyul0HOk=; b=ZKfinVte8FNsCF0YxFKXPeXkxJLDHNltp2xID7CGzps/nrNtY8t5yEmRm9CHOW77vAAOJN w9wEDH4qmH8GGKXIEkCrQ+W1Wkh8IkFIFrMyCw3AdWEoRTua5hA7W3Wlbq4eJVihZkSsFo iT7C7M8azLtW03hLlBTtrCZP9In+ocI= Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-349-AQ-ur4xUP0-ewvLe1KcImQ-1; Wed, 05 Apr 2023 02:31:46 -0400 X-MC-Unique: AQ-ur4xUP0-ewvLe1KcImQ-1 Received: by mail-yb1-f198.google.com with SMTP id v67-20020a254846000000b00b8189f73e94so14001058yba.12 for ; Tue, 04 Apr 2023 23:31:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680676306; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bYasjCShlWnYkNfJ22FS01BpuKfQldqOdM+Iyul0HOk=; b=WQV9uUMDiU0Syw9dyVZxvmT/ZmS1RuFAp5CgulQPbUc325OUGw+xKv5pdr5zcv1+LX jIvAXTxUnW0JDtu77ZW54U1BHX2SWY+weFVBj56P94Lt0bLdJo90Zgx9GRXM77Ji5K5x MHYeTwV3WmVSbdzeijR0nuPbNSp6iTT0sp8fYBy6RYr2ev8O1z6tKT2qwRxGtogQ49+J Ck87n6bUGIC/xSvlGcXzB6G8UyjMyOOv99N424qpXjaPbtiW9dGmy0SNuuwM1nx0TglY yIEQEijcpKauVaDr0s3WPdzfQmJ5FgBGA8y8W0Uotis9DYlSyvA7sFFRrNwsRE9/fxWl E9Ow== X-Gm-Message-State: AAQBX9cRtWc01b5tym1LdYrigsGm00pitJSpbSVx/s/S3eULAU6MsvYs pMit7zg7aJzvB6uhlxkf9wYr5JlddT9Ss15J3focIlUpzS4hkpU+mbblvF0jZf042b0ztaP7UqI l+sAAbIRudL7Wg19QAtQ2haChezFc X-Received: by 2002:a0d:f681:0:b0:543:6327:8d61 with SMTP id g123-20020a0df681000000b0054363278d61mr5093977ywf.42.1680676306019; Tue, 04 Apr 2023 23:31:46 -0700 (PDT) X-Google-Smtp-Source: AKy350ZTLXht4LRpj19+wre3F8ZOK/f0VxhcdJ7snGf6XKe4gqKB1FFPHpWkw9f5u5Zvkj1t2mObCA== X-Received: by 2002:a0d:f681:0:b0:543:6327:8d61 with SMTP id g123-20020a0df681000000b0054363278d61mr5093969ywf.42.1680676305730; Tue, 04 Apr 2023 23:31:45 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id h4-20020a81b644000000b0054605c23114sm3693183ywk.66.2023.04.04.23.31.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Apr 2023 23:31:45 -0700 (PDT) Message-ID: <4d8d4a40-a1f9-2e95-2e19-3d16e1556c24@redhat.com> Date: Wed, 5 Apr 2023 02:31:44 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: Monday Patch Queue Review update (2023-04-03) To: Sergey Bugaev Cc: Samuel Thibault , libc-alpha@sourceware.org References: <28fe1f1f-8fad-0da0-848e-a1d90d00cb42@redhat.com> <20230403203000.268748-1-bugaevc@gmail.com> <6521da3d-05a8-c758-29db-9948227bc2aa@redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 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_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 4/4/23 15:09, Sergey Bugaev wrote: > On Tue, Apr 4, 2023 at 8:48 PM Carlos O'Donell wrote: >> Your patches: >> >> (a) Made it to the mailing list. >> >> (b) Made it into Patchwork (which we use for patch tracking) >> >> (c) Were reviewed as part of the weekly patch queue review. >> >> - We look over patches in the meeting to see if we can help >> move them forward. >> >> (d) Did not get assigned any specific reviewer to review them. >> >> - This happens for any number of reasons e.g. lack of a person >> who feels qualified to review a subsystem or machine, >> lack of hardware to test, etc. > > Thanks for the explanation! > >> The outcome of the meeting was that we didn't find a way to help >> move your patches forward, sorry for that. > > Ah, well, based on my previous experience, we just have to patiently > wait for Samuel to find some time to review the patches :) > >> Your personal queue is here: >> >> https://patchwork.sourceware.org/project/glibc/list/?submitter=35358 >> >> Please have look over the queue to see if some of those patches have >> been committed or could have their state updated. > > Cool -- but I see that Patchwork gets confused by my somewhat liberal > use of patch series formatting: > > * "[v2] hurd: Add expected abilist files for x86_64" supersedes > "[RFC,34/34] hurd: Add expected abilist files for x86_64", so the > latter should have State = Superseded, and the former State = RFC RFC and Superseded markup is manual today. Looking at libc-alpha I see the following nesting: [RFC PATCH glibc 34/34] hurd: Add expected abilist files for x86_64 Sergey Bugaev [RFC PATCH glibc 34/34] hurd: Add expected abilist files for x86_64 Florian Weimer [PATCH v2] hurd: Add expected abilist files for x86_64 Sergey Bugaev [PATCH v2] hurd: Add expected abilist files for x86_64 Florian Weimer Patchwork considers the "[PATCH v2] hurd: ..." to be distinct patches. I believe that if you post with the subject e.g. git format-patch --rfc -v2: "[RFC PATCH v2 34/34] ..." Then it may update the patch to v2, but I haven't confirmed that. > * The same goes for "[v2] hurd: Implement sigreturn for x86_64" and > "[RFC,32/34] hurd: Implement sigreturn for x86_64" Likewise. > * Ditto for the "Alignment-respecting x86_64 trampoline.c" > mini-series, which collectively supersedes > "[RFC,18/34] hurd: Port trampoline.c to x86_64" I've never seen mini-series formatting like this. Is it used somewhere else? > (but it did grok that [PATCH v2 18.0/34] means a cover letter! unless > that was done manually) It does that manually for the 0th entry in a series. > Is there anything I should do differently when sending a replacement > for a patch (but not a v2 of the whole series) to make it easier for > Patchwork to understand what's going on? I suggest trying my comments above and we'll see if that works. I do not suggest using a mini-series. If you have to do a mini-series I think it would be better to post a v2 with a renumbered set of patches. -- Cheers, Carlos.