Re: thoughts on a Merge Request based development workflow

[Eric Wong <e@80x24.org>]

Daniel Axtens <dja@axtens.net> wrote:
> David Miller wrote:
> > Personally, I seriously want to change and move on from email, it's
> > terrible.
> 
> FWIW, I maintain patchwork and I agree with this. Email suffers from a
> gap between what can be comprehended by humans and what can be reliably
> comprehened by machines.
> 
> 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.

>  - what are the dependencies of a patch series? Does it need another
>    series first? Does it apply to a particular tree? (maintainer/next,
>    maintainer/fixes, stable?) This affects every CI system that I'm
>    aware of (some of which build on patchwork). Humans can understand
>    this pretty easily, computers not so much.

I think can do all these things off existing data in archives.
We already have pre/post-image blob IDs in git patches.
To get there, I think we'll need:

1) efficient way to map blobs -> trees -> commits -> refs
   (a reverse-mapping for git's normal DAG)

2) automatic scanning of known repos (searching what appear to
   be pull-requests, similar to what pr-tracker-bot does).

None of which requires patch senders to do anything differently.

git format-patch features such as --base and --range-diff can
certainly help with this, and it's probably easier to train people
to use newer options in existing tools than new tools, entirely.

> 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

Unlike in 2005 when git started; things like Xapian and SQLite
are much more mature and I'm comfortable leaning on them to
solve harder problems.