[Buildroot] More maintainers

[James Hilliard]

On Thu, Sep 3, 2020 at 10:24 AM Thomas Petazzoni
<thomas.petazzoni at bootlin.com> wrote:
>
> Hello Avraham,
>
> On Thu, 3 Sep 2020 18:44:27 +0300
> Avraham Shukron <avraham.shukron at gmail.com> wrote:
>
> > For what it's worth I think that the mail-based contribution process is
> > part of the problem.
> > With a decent Git server like GitHub/GitLab patches could be reviewed more
> > easily.
> > A CI pipeline could run tests that will give immediate feedback for any
> > pull request.
> > More importantly, it'll dramatically reduce the barrier for new and young
> > contributors.
>
> This has been discussed multiple times in the past in Buildroot, and in
> other open-source projects. There is even as we speak some pretty
> intense debate in the Linux kernel community about this.
Having CI run automatically when pull requests are made is extremely
useful for reducing reviewer workload in my experience, Linux has somewhat
unique requirements due to having many subsystem staging trees, this doesn't
apply to buildroot however so I see little reason that we need to follow the
Linux workflows closely.

My internal company workflows for buildroot based projects use buildbot
integrated with gitlab for running builds on each commit automatically.
I use buildbot workers so that I can use a cheap VPS for hosting the buildbot
master interface while running the actual builds on powerful bare metal
systems. It may also make sense to entirely replace the current autobuilder
setup with something buildbot based(buildbot is extremely flexible/scriptable).

Personally I would like to see buildroot move to something along the lines
of the freedesktop workflows using gitlab or similar where there is integrated
CI on each pull request.
>
>
> As we've seen from the discussion here, the Buildroot issue is not a
> lack of contribution, but a lack of review from trusted and experienced
> reviewers, and a lack of maintainers time. So while I'm all for new
> contributors and contributions, I don't think reducing the barrier is
> really key here. Also, I've always been skeptical about this statement
> that using Github reduces the barrier to entry. When you contribute to
> a project, is really sending a patch over e-mail the difficult part
> compared to understanding the code base, debugging the issue you've
> found or implementing the feature you wanted ? Really installing "git
> send-email" is a no-brainer straightforward process that is
> ridiculously easy even compared writing any single change in the code
> base with a decent commit message. Aren't we using this "reducing the
> barrier" argument a bit inappropriately here ?
I disagree that installing "git send-email" is straight forward, it's something
that's highly specific to ones mail setup and there are often significant
roadblocks, see https://twitter.com/mjg59/status/1299473271721664512
as an example. Personally I don't like git send-email since it requires
bypassing various 2FA security features and generally encourages bad
security practices.
>
> I believe I can say that all four Buildroot maintainers have a very
> strong preference for and a very optimized workflow to work with e-mail
> based patch submission and review.
>
> Somewhat related, recently a patch series I submitted last year to
> OpenWrt (which wasn't merged) got picked up by someone else, and
> re-submitted with new updates and fixes. Due to being the original
> author, I was in copy of all the Github discussion that took place. And
> I found it absolutely impossible and awful to follow the different
> revisions of the patch series, to which version of the patch series the
> comments were being made, etc.
>
> Perhaps for some people the Github pull request workflow makes sense,
> but I believe it's important to recognize and realize that there are
> also people for which this workflow doesn't make sense.
For a project like buildroot where there is only one mailing list I don't see
much advantage to the patch based workflow. From my understanding
the main advantage to using email patch based workflows is that you can
CC multiple subsystem mailing lists. Also replying to threads is non-trivial
as well as you have to do some crazy mbox importing to even respond to
an existing mailing list post if you are not already subscribed to that list.
>
> > Buildroot is all about using simple and familiar tools like make and
> > Kconfig, and I personally think that this principle should also be applied
> > to the contribution process and right now buildroot is one of the last
> > active open source projects using the mailing list approach.
>
> This is a very biased statement: there are still plenty of open-source
> projects that use e-mail based contribution workflow. I don't think we
> can call Linux or U-Boot "inactive" projects. Can we? :-)
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot