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 CE7CEC4360C for ; Tue, 8 Oct 2019 21:36:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A87EF21835 for ; Tue, 8 Oct 2019 21:36:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729854AbfJHVg1 (ORCPT ); Tue, 8 Oct 2019 17:36:27 -0400 Received: from dcvr.yhbt.net ([64.71.152.64]:40494 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728054AbfJHVg1 (ORCPT ); Tue, 8 Oct 2019 17:36:27 -0400 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 54E401F4BD; Tue, 8 Oct 2019 21:36:26 +0000 (UTC) Date: Tue, 8 Oct 2019 21:36:26 +0000 From: Eric Wong To: Rob Herring Cc: Daniel Axtens , David Miller , sir@cmpwn.com, nhorman@tuxdriver.com, workflows@vger.kernel.org Subject: Re: thoughts on a Merge Request based development workflow Message-ID: <20191008213626.GB8130@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> <20191008060302.vqf4ogk6s37ghrp3@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: workflows-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: workflows@vger.kernel.org Rob Herring wrote: > On Tue, Oct 8, 2019 at 1:03 AM Eric Wong wrote: > > > > 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 :> > > +1 to what Steven said. PW is my todo list. That's never worked well > within my mail client. OK, I admit my assumptions around delegation/state were way off :> What about a control language similar to debbugs? https://debbugs.gnu.org/server-refcard.html The goal is to have something that can be reproduced, replayed and regenerated by any client without centralized dependencies. Integer IDs used by debbugs would be replaced by Message-IDs, at least. > > I prefer actual communication of delegation/state be done via > > normal English. Relying on states/tickets/severities/etc > > unnatural and often leads to confusion. Fwiw, I often get "critical" vs "grave" and "serious" vs "important" severities mixed up in debbugs. That would be confusing to non-native speakers. > > 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... > > I'm pretty sure solving managers workflows is a non-goal of this list. OK :) And yeah, on second thought, NLP would probably be too fuzzy, especially for non-native speakers. But I think something along the lines of debbugs control commands could be a good compromise if it's regeneratable.