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.
next prev parent 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).