Re: thoughts on a Merge Request based development workflow

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Oct 08, 2019 at 04:32:49PM -0400, Don Zickus wrote:
> > This doesn't mean that forges are entirely out -- but they must remain mere
> > tools that participate in a globally decentralized, developer-attestable,
> > self-archiving messaging service. Maybe let's call that "kernel developer
> > bus" or "kdbus" -- pretty sure that name hasn't been used before.
> 
> If we flipped it around and used today's git-pull-request emails as trigger
> for forges to run their services, does cover some of your concerns?

Not really, because it doesn't preserve any records. A pull request is a
pointer to some code in a git repository somewhere. Like any pointer, it
is neither self-contained nor long-lived:

- the repo can be gone a month later (or that branch deleted)
- the PR does not preserve any discussions that happened around that
  code such as bug reports, test success/fail matrices, or peer reviews

It's also pretty inefficient, because it requires that the pull-request
submitter hosts a 1.5GB repository on a fast permanently-available
connection just so they can share a few lines of changes.

> git-pull-request emails can skip the patch-translation layer (like
> patchwork), run the automated tests, and utilize the current maintainer
> workflows.

Where do the test reports go after they are completed? How does the
maintainer find out that the tests succeeded? How does the next
developer after them -- say, 3 years later -- find out what tests ran
against that changeset before it was merged?

Instead of consolidating the fragmented landscape of Linux development,
we are further fracturing it and making it lossier. Currently, archival
efforts like lore.kernel.org at least preserve all discussions/reports
cc'd to the LKML, but I'm afraid that forges will render large parts of
the development process completely opaque.

I suggest that we stick to patch-based workflows and develop better
tooling and distribution fabric to replace SMTP -- redecentralizing
things in the process.

> The email issue is hard to resolve as some folks feel like it should be a
> primary vehicle while others feel it should be a secondary vehicle.

If forges are merely participants in the communication fabric, then it
doesn't matter which one is primary. In fact, email then becomes just
another bridge, so those who are not interested in switching away from
their current email-based workflow can continue using email.

-K