[OE-core] Why openembedded-core mailing list is now author of some patches?

[Khem Raj]

On Sun, Mar 24, 2019 at 4:29 AM <richard.purdie at linuxfoundation.org> wrote:
>
> On Sun, 2019-03-24 at 01:41 -0400, Neal Gompa wrote:
> > Has anyone considered the (perhaps radical?) idea that the sending
> > changes as an email patch series should be replaced? For example, if
> > git.openembedded.org and git.yoctoproject.org were overlaid with
> > Pagure[0] frontends (it uses Gitolite internally, so you can have
> > multiple frontends in place for the same Git repos), it would be easy
> > enough to support pull requests, even from external Git servers. And
> > with that model, OE/Yocto can use CI properly (e.g. using Jenkins,
> > Zuul, or something else) rather than building more hacks on top of
> > emails.
>
> Using alternatives does get discussed periodically.
>
> It depends which problem(s) we're trying to solve really. I don't
> believe that pagure/github/gitlab/etc would solve a CI problem since
> our real CI challenge is we can't run our test matrix in a time frame
> which allows testing of every patch.
>
> If you mean patchtest/patchwork testing, that is a small subset of CI
> and has to be carefully designed as its effectively remote code
> injection. I appreciate the likes of travis also have ways of
> mitigating potential issues there, there are a lot of ways it could be
> done, patchtest was the way some people had time to make it work.
>
> I'd note that pagure also has an issue tracking system so it isn't just
> a front end to gitolite, its also looking to replace bugzilla.
>
> I actually think our main issue is people with time to help work on
> things. If you're saying that switching to pagure will mean we then
> have number of new developers with time to help us on the project then
> we should seriously consider it. I'm not convinced that is the main
> barrier there to that, or that would be the outcome. I do agree it may
> be a barrier to occasional submitters unfortunately though.
>

I believe if there are no occasional submitters than eventually there are less
regular contributors. So in a way having it easy for occasional contributors
is a way for increasing chances of making more regular contributors.

several projects are thriving without using mailing lists for patches these days
some of them are full distros too.

Mailing lists were only way to share before these infrastructures existed
but aren't necessarily a better workflow than others as of today. It does have
a automation problem, where human hand is needed more than some of
these new tools, where automation is quite good in the whole workflow.

> Also, keep in mind these pull models work well for cases where you have
> a small number of reviewers. The mailing list model works better where
> you have a wider team looking at review. I suspect if we switched to
> something which didn't have a mail interface, we'd probably lose much
> of the review we currently get and mean that we'd rely on a small
> number of peope for all the review.
>
> Obviously this is all my personal opinion and I'm very mindful of that,
> I don't want to be seen to be shutting down ideas and impacting
> innovation. We do also need to be mindful of what we have where it is
> working too though.
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core