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

Bruce Ashfield bruce.ashfield at gmail.com
Sun Mar 24 22:53:04 UTC 2019


On Sun, Mar 24, 2019 at 7: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.
>
> 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.

This is my main concern as well. Really, the patch quantity in the oe
lists isn't much compared to most of the projects that I monitor, so the
patches being sent isn't much of an issue.

Once things go to the background/backend of pull requests, without
a patch set being sent as well, a lot of eyes on changes tend to be
lost. But of course mixes of the various approaches can make sense,
it isn't like many of us don't push to our contrib branch, send the pull
request and broadcast the patches .. hence both are already in play.

Cheers,

Bruce

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



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


More information about the Openembedded-core mailing list