From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1BDBC4360C for ; Tue, 8 Oct 2019 06:03:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CBED820673 for ; Tue, 8 Oct 2019 06:03:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729375AbfJHGDD (ORCPT ); Tue, 8 Oct 2019 02:03:03 -0400 Received: from dcvr.yhbt.net ([64.71.152.64]:45548 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728297AbfJHGDD (ORCPT ); Tue, 8 Oct 2019 02:03:03 -0400 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 92B591F4BD; Tue, 8 Oct 2019 06:03:02 +0000 (UTC) Date: Tue, 8 Oct 2019 06:03:02 +0000 From: Eric Wong To: Daniel Axtens Cc: David Miller , sir@cmpwn.com, nhorman@tuxdriver.com, workflows@vger.kernel.org Subject: Re: thoughts on a Merge Request based development workflow Message-ID: <20191008060302.vqf4ogk6s37ghrp3@dcvr> References: <20190924182536.GC6041@hmswarspite.think-freely.org> <20191007.173329.2182256975398971437.davem@davemloft.net> <87zhicqhzg.fsf@dja-thinkpad.axtens.net> <20191008003931.y4rc2dp64gbhv5ju@dcvr> <87wodgqb86.fsf@dja-thinkpad.axtens.net> <20191008021125.slr35o3tmwphxfpz@dcvr> <87pnj7rkbp.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87pnj7rkbp.fsf@dja-thinkpad.axtens.net> Sender: workflows-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: workflows@vger.kernel.org Daniel Axtens wrote: > >> >> For example: > >> >> > >> >> - is a given series a revision of a previous series? Humans can change > >> >> the name of the cover letter, they can re-order or drop patches, > >> >> split and merge series, even change sender, and other humans just > >> >> figure it out. But if I try to crystalise that logic into patchwork, > >> >> things get very tricky. This makes it hard to build powerful APIs > >> >> into patchwork, which makes it harder to build really cool tools on > >> >> top of patchwork. > >> > > >> > I'm confident that we can build much of that logic off search > >> > and do similar things to what git does with rename detection. > >> > >> A lot of people on this list are confident of a great many things :) > >> > >> There should be an API in the next minor version of Patchwork that > >> allows you to set patch relations. I would encourage you to try to build > >> this - if it works, we can plug it in to the core. > > > > Manually set relations should not be needed if people use > > format-patch with --interdiff or --range-diff. > > > > A well-tuned search engine will be able to figure out the > > preceding series using the git blob IDs from interdiff or commit > > IDs from range-diff. > > > > No need to introduce extra metadata into the system, especially > > not in a way that can't be reproduced. Reuse what we have. > > > > Even without interdiff or range-diff, it should be possible to > > determine relationships based on common pre-image blob IDs > > if the sender used the same base. > > As I said, I'd be really happy to see this piggy-back on the API once it > lands. Sorry, I'm not sure who's piggy-backing off who :) I intend to keep the raw/gzipped-text URLs in public-inbox stable so anything can query it. I'm not sure if there's anything for public-inbox to query from patchwork's API for this, since all the info public-inbox needs is in the archives. The interdiff stuff is easier and be done sooner in public-inbox since it won't require indexing changes. So maybe by early Nov. range-diff will require the ability to scan repos, so more work to get that mapping into place. > >> >> Non-email systems have an easier time of this: with gerrit (which I'm > >> >> not a big fan of, but just take it as an example) you push things up to > >> >> a git repository, and it requires a change-id. So you can track the base > >> >> tree, dependencies, and patch revisions easily, because you build on a > >> >> richer, more structured data source. > >> > > >> > Right, decentralization is a HARD problem; but it starts off > >> > with centralization-resistance, a slightly easier problem to > >> > solve :) > >> > > >> > The key is: don't introduce things which mirrors can't reproduce > >> > >> Mirrors already can't meaningfully reproduce patchwork. They can only > >> make a read-only copy of some of the data, but it's not enough to spin > >> up a new identical instance. > > > > Right, that seems to be a consequence of not having the > > prerequisite storage or search that public-inbox does: > > I don't think so. I think it's because patchwork allows you to log in > and perform actions like change state and delegate patches. That's not a > thing that public-inbox has in scope. It seems like those things are done to appease managerial types rather than people who actually do work :> I prefer actual communication of delegation/state be done via normal English. Relying on states/tickets/severities/etc unnatural and often leads to confusion. And maybe NLP (natural language processing) can go far enough where we can build states to show managers using sentences like: Alice: "Bob, can you review these patches for foo?" Bob: "Sorry Alice, busy on the refactoring bar, maybe Eve can do it" Eve: "Alice, sure I can review those patches" I have no experience with NLP, though...