Re: thoughts on a Merge Request based development workflow

[Don Zickus <dzickus@redhat.com>]

On Mon, Oct 07, 2019 at 09:17:04PM -0400, Steven Rostedt wrote:
> On Tue, 08 Oct 2019 10:00:03 +1100
> Daniel Axtens <dja@axtens.net> wrote:
> 
> > 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.
> 
> I believe we all want a new system that can handle this, but still be
> able to work with email. Patchwork requires to read all emails and
> figure out what to do with it. This workflow doesn't need to do that.
> But it should be able to send out emails on comments, and a reply to
> one of those should easily be put back into the system.
> 
> As for adding patches, we can push to a git tree or something that the
> tool could read. It's much easier to know what to do with a branch then
> email. A rebase could be a new version of the series (and we should
> probably archive the original version).

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.

Thanks!

Cheers,
Don