From: Daniel Axtens <dja@axtens.net>
To: Eric Wong <e@80x24.org>
Cc: 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, 08 Oct 2019 21:06:23 +1100 [thread overview]
Message-ID: <87muebr1pc.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <20191008060302.vqf4ogk6s37ghrp3@dcvr>
Eric Wong <e@80x24.org> writes:
> 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.
>
OK, you're going in a completely different direction then.
>> >> >> 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.
This is not a widely held view amongst lists and maintainers that use
patchwork.
> 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 suspect from our interactions that continuing with this conversation
isn't going to be of much value to either of us. Good luck with your
approach.
Regards,
Daniel
next prev parent reply other threads:[~2019-10-08 10:06 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 [this message]
2019-10-08 13:19 ` Steven Rostedt
2019-10-08 18:46 ` Rob Herring
2019-10-08 21:36 ` Eric Wong
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=87muebr1pc.fsf@dja-thinkpad.axtens.net \
--to=dja@axtens.net \
--cc=davem@davemloft.net \
--cc=e@80x24.org \
--cc=nhorman@tuxdriver.com \
--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).