workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Rob Herring <robh@kernel.org>
Cc: Daniel Axtens <dja@axtens.net>,
	David Miller <davem@davemloft.net>,
	sir@cmpwn.com, nhorman@tuxdriver.com, workflows@vger.kernel.org
Subject: Re: thoughts on a Merge Request based development workflow
Date: Tue, 8 Oct 2019 21:36:26 +0000	[thread overview]
Message-ID: <20191008213626.GB8130@dcvr> (raw)
In-Reply-To: <CAL_JsqJOR89V8dKnpHpY2phnPRozVxdv+rnsT0sfxdRymgjxLA@mail.gmail.com>

Rob Herring <robh@kernel.org> wrote:
> On Tue, Oct 8, 2019 at 1:03 AM Eric Wong <e@80x24.org> wrote:
> >
> > Daniel Axtens <dja@axtens.net> 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.

  reply	other threads:[~2019-10-08 21:36 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 18:25 thoughts on a Merge Request based development workflow Neil Horman
2019-09-24 18:37 ` Drew DeVault
2019-09-24 18:53   ` Neil Horman
2019-09-24 20:24     ` Laurent Pinchart
2019-09-24 22:25       ` Neil Horman
2019-09-25 20:50         ` Laurent Pinchart
2019-09-25 21:54           ` Neil Horman
2019-09-26  0:40           ` Neil Horman
2019-09-28 22:58             ` Steven Rostedt
2019-09-28 23:16               ` Dave Airlie
2019-09-28 23:52                 ` Steven Rostedt
2019-10-01  3:22                 ` Daniel Axtens
2019-10-01 21:14                   ` Bjorn Helgaas
2019-09-29 11:57               ` Neil Horman
2019-09-29 12:55                 ` Dmitry Vyukov
2019-09-30  1:00                   ` Neil Horman
2019-09-30  6:05                     ` Dmitry Vyukov
2019-09-30 12:55                       ` Neil Horman
2019-09-30 13:20                         ` Nicolas Belouin
2019-09-30 13:40                         ` Dmitry Vyukov
2019-09-30 21:02                     ` Konstantin Ryabitsev
2019-09-30 14:51                   ` Theodore Y. Ts'o
2019-09-30 15:15                     ` Steven Rostedt
2019-09-30 16:09                       ` Geert Uytterhoeven
2019-09-30 20:56                       ` Konstantin Ryabitsev
2019-10-08  1:00                     ` Stephen Rothwell
2019-09-26 10:23           ` Geert Uytterhoeven
2019-09-26 13:43             ` Neil Horman
2019-10-07 15:33   ` David Miller
2019-10-07 15:35     ` Drew DeVault
2019-10-07 16:20       ` Neil Horman
2019-10-07 16:24         ` Drew DeVault
2019-10-07 18:43           ` David Miller
2019-10-07 19:24             ` Eric Wong
2019-10-07 15:47     ` Steven Rostedt
2019-10-07 18:40       ` David Miller
2019-10-07 18:45       ` David Miller
2019-10-07 19:21         ` Steven Rostedt
2019-10-07 21:49     ` Theodore Y. Ts'o
2019-10-07 23:00     ` Daniel Axtens
2019-10-08  0:39       ` Eric Wong
2019-10-08  1:26         ` Daniel Axtens
2019-10-08  2:11           ` Eric Wong
2019-10-08  3:24             ` Daniel Axtens
2019-10-08  6:03               ` Eric Wong
2019-10-08 10:06                 ` Daniel Axtens
2019-10-08 13:19                   ` Steven Rostedt
2019-10-08 18:46                 ` Rob Herring
2019-10-08 21:36                   ` Eric Wong [this message]
2019-10-08  1:17       ` Steven Rostedt
2019-10-08 16:43         ` Don Zickus
2019-10-08 17:17           ` Steven Rostedt
2019-10-08 17:39             ` Don Zickus
2019-10-08 19:05               ` Konstantin Ryabitsev
2019-10-08 20:32                 ` Don Zickus
2019-10-08 21:35                   ` Konstantin Ryabitsev
2019-10-09 21:50                     ` Laura Abbott
2019-10-10 12:48                       ` Neil Horman
2019-10-09 21:35                 ` Laura Abbott
2019-10-09 21:54                   ` Konstantin Ryabitsev
2019-10-09 22:09                     ` Laura Abbott
2019-10-09 22:19                       ` Dave Airlie
2019-10-09 22:21                     ` Eric Wong
2019-10-09 23:56                       ` Konstantin Ryabitsev
2019-10-10  0:07                         ` Eric Wong
2019-10-10  7:35                         ` Nicolas Belouin
2019-10-10 12:53                           ` Steven Rostedt
2019-10-10 14:21                           ` Dmitry Vyukov
2019-10-11  7:12                             ` Nicolas Belouin
2019-10-11 13:56                               ` Dmitry Vyukov
2019-10-14  7:31                                 ` Nicolas Belouin
2019-10-10 17:52                     ` Dmitry Vyukov
2019-10-10 20:57                       ` Theodore Y. Ts'o
2019-10-11 11:01                         ` Dmitry Vyukov
2019-10-11 12:54                           ` Theodore Y. Ts'o
2019-10-14 19:08                         ` Han-Wen Nienhuys
2019-10-15  1:54                           ` Theodore Y. Ts'o
2019-10-15 12:00                             ` Daniel Vetter
2019-10-15 13:14                               ` Han-Wen Nienhuys
2019-10-15 13:45                                 ` Daniel Vetter
2019-10-16 18:56                                   ` Han-Wen Nienhuys
2019-10-16 19:08                                     ` Mark Brown
2019-10-17 10:22                                       ` Han-Wen Nienhuys
2019-10-17 11:24                                         ` Mark Brown
2019-10-17 11:49                                     ` Daniel Vetter
2019-10-17 12:09                                       ` Han-Wen Nienhuys
2019-10-17 12:53                                         ` Daniel Vetter
2019-10-15 16:07                           ` Greg KH
2019-10-15 16:35                             ` Steven Rostedt
2019-10-15 18:58                             ` Han-Wen Nienhuys
2019-10-15 19:33                               ` Greg KH
2019-10-15 20:03                                 ` Mark Brown
2019-10-15 19:50                               ` Mark Brown
2019-10-15 18:37                           ` Konstantin Ryabitsev
2019-10-15 19:15                             ` Han-Wen Nienhuys
2019-10-15 19:35                               ` Greg KH
2019-10-15 19:41                               ` Konstantin Ryabitsev
2019-10-16 18:33                                 ` Han-Wen Nienhuys
2019-10-09  2:02           ` Daniel Axtens
2019-09-24 23:15 ` David Rientjes
2019-09-25  6:35   ` Toke Høiland-Jørgensen
2019-09-25 10:49   ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191008213626.GB8130@dcvr \
    --to=e@80x24.org \
    --cc=davem@davemloft.net \
    --cc=dja@axtens.net \
    --cc=nhorman@tuxdriver.com \
    --cc=robh@kernel.org \
    --cc=sir@cmpwn.com \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).