Re: thoughts on a Merge Request based development workflow

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 8 Oct 2019 12:43:09 -0400
Don Zickus <dzickus@redhat.com> wrote:

> Thanks for the thoughts.  Your thoughts here and your bugzilla example make
> sense and ties into some of the work we are experimenting with, with a small
> group at Red Hat.  My only sticky point is the initial patch submission.
> Pushing to a forge like github, gerrit, or gitlab makes a ton of sense like
> you said above.  But what do we do with folks who still email patches
> initially (instead of the git-push)?
> 
> What should be the expectations there?  Leverage patchwork to create a 'git
> push'?  Reject the patchset?  Something else?  Curious.

I think we are not just talking about reusing patchwork (unless that
becomes the starting point). But let's use patchwork as a starting
point for my thoughts about this. One would email the mailing list, and
also Cc a "listener" (like patchwork). Note, the one thing I dislike
about patchwork is that it requires to read a list. I rather have it
just be something that gets Cc'd to trigger it.

Anyway, when this "listener" gets an email, it goes into the system.
Now the maintainer can get an email from this system, or read the
system directly from a web browser or whatever client they choose. They
reply to the system, and this goes to the original submitter via email
(with links to how to use the system directly). The submitter, can then
use the system to send a v2, and ever perhaps reply to it via email with
some key word that will tell the system it is v2, or a comment.

I think we need to standardize on keywords to trigger the system
properly, if we are to use email (its up to the email user to get those
keywords right), or they can go directly to the system interface (be it
a web browser, or whatever), and then they don't need to worry about
keywords as the system would handle that directly.

Does this make sense?

-- Steve