From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108570 invoked by alias); 6 Dec 2019 16:44:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 108515 invoked by uid 89); 6 Dec 2019 16:44:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=mistaken, merges, sk:optiona, difficulty X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2019 16:44:53 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id xB6Gijm6001278 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Dec 2019 11:44:50 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca xB6Gijm6001278 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1575650692; bh=rOrt1WGs9qPpAv0BqvUFor9qfg97jy49E2GSDkMGAHE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FB560EJ24MRac6Mi15+Pk0NfOWs7we14qkldx0odokSfxlccaOyIjCbHAKiF8C8+f Es0/HY4dQon7SweGs2z6I1Ppk65BBIC5R3KQFS29KE+f64DmHAYRL/6wKhFeaNFtLY 2K528J/x7Vh2aOsrBY7lxDBV9dyxgvS/SRrXLCvc= Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 971CD1E5FA; Fri, 6 Dec 2019 11:44:45 -0500 (EST) Subject: Re: Gerrit status update To: Tom Tromey Cc: "gdb-patches@sourceware.org" References: <93b1726e-d5d9-f264-4efc-79b0cdb034aa@polymtl.ca> <87y2w7moag.fsf@tromey.com> From: Simon Marchi Message-ID: Date: Fri, 06 Dec 2019 16:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <87y2w7moag.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00232.txt.bz2 On 2019-11-22 7:25 p.m., Tom Tromey wrote: > Simon> A newer version of Patchwork includes a git hook that can supposedly > Simon> automatically close patches when they are pushed to the git repository: > Simon> https://patchwork.readthedocs.io/en/latest/deployment/installation/#optional-configure-your-vcs-to-automatically-update-patches > ... > Simon> I am just a bit skeptical about how well (if it does it at all) > Simon> Patchwork handles patches or series versions. If I send a v1 series > Simon> with 15 patches, then a v2 with 17 patches, including a few renamed > Simon> subjects, how does it cope with that? > > I'm not too worried about this scenario (see below) but I think one to > test is if a patch is abandoned from the middle of a series. Making > this work requires some notion of a series in the first place. I think > the new Patchwork has this, but it's been a while since I looked. Yes, it does. We could give series an id of their own (Series-Id?) and mark all the patches from v1 as obsolete when v2 is sent. I'm not sure if and how that Series-Id could be automatically generated and included in the cover letter of subsequent versions, but that's just a technical detail. I'm not too worried about this scenario in the first place. If you send a lone patch and decide to abandon it, you would need to go to Patchwork to mark it as abandonned. If you drop a patch from a series, it's the same. > > Simon> Gerrit is able to track the multiple versions of a change because we > Simon> insert a unique Change-Id in the commit log of each patch. This is very > Simon> reliable, and it would make handling of new versions/merged patches very > Simon> accurate. But it goes against the Patchwork design: > > Simon> https://patchwork.readthedocs.io/en/latest/usage/design/ > > Simon> "Don’t pollute the project’s changelogs with Patchwork poop > > Simon> A project’s changelogs are valuable - we don’t want to add Patchwork-specific metadata." > > Simon> So unfortunately, we won't get that from upstream. But it would always > Simon> be possible to modify Patchwork to add this feature for our own > Simon> enjoyment. > > Yeah... I think this bit of Patchwork dogma is simply mistaken. > Reliability requires a patch ID that does not vary; and since git > doesn't provide this, it has to be provided externally. I reached out to Patchwork devs, and it seems like they would be open to the idea of supporting tracking patches using a Change-Id: https://github.com/getpatchwork/patchwork/issues/327#issuecomment-561573729 I think the idea is simply that it should not be mandatory to have them to use Patchwork. > Furthermore, we already accepted these IDs for gerrit. I find them > readily ignorable. > > I think modifying Patchwork to do this is very simple. First, we could > either re-use the gerrit commit hook, or write our own (I wrote one > once, it's in my github). > > Second, in the Patchwork tree is a file, tools/post-receive.hook. This > is a shell script that has a function to get the patch hash: > > get_patchwork_hash() { > local hash > hash=$(git diff "$1~..$1" | python $PW_DIR/hasher.py) > echo "$hash" > test -n "$hash" > } > > I think all that's needed is to replace this with something to extract > our ID. This can be done with "git interpret-trailers --parse". Yep. > One other thing gerrit provides is the ability to fetch patches from > gerrit. This can be done with patchworks as well, using its CLI. > However, I imagine it is less reliable, since it isn't git on the other > end... like, with git you can do 3-way merges, but with patchworks you > couldn't. When the author has used send-email, "git am -3" usually works well. I hope that git-pw uses it. > I've looked at patchworks a little, as you can tell; but I haven't > looked at gerrit at all. So, I have no idea of the relative difficulty > of adding the features we want to gerrit. >From what I saw, it's way more than the time I have to put on it without becoming a full-time Gerrit developer. Simon