From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E4C311F4C1 for ; Fri, 25 Oct 2019 16:28:38 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=LAwCqzsPWGM+nN4F RII1f85ZDZYEAuAk0EIz+zaq1t2lKALNAoL9/HUvxXBUHgrSuAYJ4GP5jhzTbT+C HN9Q7PPWTm2Qzy6PfSUn86ErBnMcdv7h1gKg4WxwmRWjZWmlO7xwmYnVAWUfkxaV wf80l3woScsylesP04LasgPuRfA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=3XnPIf1awjpwizFu0Ez6Tx twaOE=; b=NFQuyQwy97jA6Zb9T0Zq2ySIeGK6O1RvSB2jkYmYYgePBro3QOTyEw hvCuqBEyIhpr42Syqdw5OHWfVnMALhs0MkiZ+qgh11vXJX+kXkhVACEp1JcWlCbZ n/F5kcNN22Kgi7gjrP4Xkk1uuL1Hh3gEi/M0x9EoGZoxRdXgiP2bI= Received: (qmail 124538 invoked by alias); 25 Oct 2019 16:28:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 124264 invoked by uid 89); 25 Oct 2019 16:28:35 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: smtp.polymtl.ca DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x9PGSJ1K028514 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1572020905; bh=CwlqTTfUgtZDL+7vNTs69Z0HikXs430L4eLKXwTXLqc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZQ61YnoVkjcfayBZkSph9jkAwp8CJJDg0vPSINGxz+XfsVCMu0tnk4hUknXAAUS6U 52ZmRU+YffcoDZYX0EWs7qxgTqlnrSMBho3C7MNgJ9da91UHmr1lKs2+0etmfQXwQ/ fVDIWeuR6gj0dZ5PWF5YScPbSE72lffW6XEXedm0= Subject: Re: Setup non-pushing gerrit instance for glibc. To: Joseph Myers Cc: Sergio Durigan Junior , "Carlos O'Donell" , libc-alpha , Jonathan Nieder References: <2e93ece9-386b-c587-9355-33a4695a3f02@redhat.com> <8b64d48f-3fd6-fa06-5b33-8daa97661fef@redhat.com> <87tv7xvaw7.fsf@redhat.com> <0374dde9-0b49-0af4-c718-e894b59e680f@polymtl.ca> From: Simon Marchi Message-ID: <6de10362-5f23-6d06-9636-4a79370e03d4@polymtl.ca> Date: Fri, 25 Oct 2019 12:28:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 2019-10-25 12:10 p.m., Joseph Myers wrote: >>> There is a difference of *intent* between changes that depend on one >>> another and a patch series. A patch series is saying: >>> >>> * there is a common purpose motivating the patches; and >> >> In Gerrit, you'd probably use topics to indicate that many changes have >> a common purpose (whether they are interdependent or not). >> >> https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics > > If using a topic were to mark the patches as a patch series (including > marking email subjects and threading them accordingly), that would be > fine. I don't think it's necessary for simply pushing multiple changes at > once to be the way you cause something to be handled as a patch series, if > topics are the idiomatic concept in gerrit that corresponds to a patch > series as generated by git-format-patch. I don't believe the topic is included in the email (at least not the subject), but that is likely possible to do. For example, including it in the prefix tag: [review my-topic-name] I think that would help, but we would still be missing the information about the order of the patches. Any ideas for that? >>> There's also the variant of patch series that are explained in the cover >>> letter (or in other text not intended for the final commit) as being split >>> only for review purposes and intended to be squashed for commit, if the >>> pieces most convenient for review don't form bisectable commits. I'm not >>> sure how much any review system needs to know about the distinction >>> between the two kinds of patch series if it's not pushing the commits >>> itself. >> >> I don't think there would be a problem with that, except that the two emails >> on the mailing would not be threaded together. More thoughts about that >> below. > > Well, there would be issues if you wanted gerrit to push changes itself. > And how does the "identify this as being the same change" system (for > knowing when something has been committed) work if multiple separately > reviewed patches are squashed into one commit? In that case, I would keep in the squashed commit the Change-Id of the first commit (i.e. the commit that contains the logical change, not the generated stuff). When pushing that commit, it will auto-close the first change. The last/final version of that change would therefore be the full thing, including the generated stuff. I would then need to abandon the second commit. In the reason field (when you click Abandon) I would say that since the content has been squashed in the parent change, which is now merged, this one is no longer needed. > (Is the valid syntax for Change-Ids documented anywhere? In particular, > is it OK to write a human-readable Change-Id oneself?) It's not mentioned here [1] so I suppose it's not documented. We would have to look in the source code (or just try it) to see what's supported. [1] https://gerrit-review.googlesource.com/Documentation/user-changeid.html Simon