Re: thoughts on a Merge Request based development workflow

[Laura Abbott <labbott@redhat.com>]

On 10/8/19 5:35 PM, Konstantin Ryabitsev wrote:
> 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.
> 

I know this is an issue that Outreachy interns across projects have had in
the past with trying to sync large git repos across laggy connections.

The advantage of the pull request though is that it's atomic. It has
the full history for testing. When you test a commit, you always have the
correct base. With a patch, you aren't guaranteed a base for testing.

I know there have been various attempts to try and give a base for
testing but it doesn't seem like anything has caught on enough (or maybe
it has and I've missed it completely)

>> 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'd argue a single forge would make things _more_ transparent. Sure if
things get cc'd to LKML they get archived but there's still plenty
of submissions that never get sent to LKML and only to a particular
list. There have been many times I've had to go searching around for
a particular patchwork for a particular list to get a patch because
the submitter forgot/chose not to cc LKML. The weakness of a single
point of failure is also an advantage: There is a single location for
all discussion and bugs and merge requests. Of course this only works
if the forge is considered the source of truth.

Thanks,
Laura

> 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
>