[Buildroot] More maintainers

Yann E. MORIN yann.morin.1998 at free.fr
Sat Aug 29 09:50:23 UTC 2020


Thomas, Adam. Angelo, All,

On 2020-08-27 22:39 +0200, Thomas Petazzoni spake thusly:
> On Thu, 27 Aug 2020 10:34:31 -0700
> Adam Duskett <aduskett at gmail.com> wrote:
> > Angelo and I were discussing the state of patches today in regards to Buildroot.
> > It seems like the project could benefit from a few more maintainers of
> > the project.
> > We both understand that this is a volunteer project and that we are
> > all adults and have a life outside of the project, and as such, we
> > can't expect instant reviews on every submitted patch. However, as the
> > project continues to grow in popularity, more patches will continue to
> > be offered at an ever-increasing rate. This popularity increase is
> > excellent news for the project, but also comes at the cost of more
> > time and effort in regards to the number of patches and fixes in the
> > queue to review and test.
> > 
> > As such, we would both like to throw our hat in the ring to help
> > maintain the project. We both don't have all the time in the world,
> > but any amount of help on the project can help alleviate the primary
> > maintainers.
> 
> I agree that we probably need to extend or change the current
> maintainers team.
> 
> However, what is also true is that very little patches that are posted
> get review from other contributors. And this is actually what is the
> most important. When I see a patch series that has been looked at by 1
> or 2 other people that I trust and who gave their Reviewed-by, I will
> apply such a patch series very easily, without almost looking at it.
> 
> You can go have a look at
> https://patchwork.ozlabs.org/project/buildroot/list/ and see how many
> patches in the list have a Reviewed-by tag. Very few. This is
> definitely something where everybody can help, and it is by doing such
> reviews that the trust will increase with the current maintainers,
> which is key for becoming a maintainer IMO.
> 
> What do you think ?

I do agree with all of this, both the remarks from Adam and Angelo, and
the feedback from Thomas.

The burden is not in applying patches; this is the easy part.

What really takes time is actually reviewing patches: understanding the
problem, understanding how it is fixed, why it is fixed in such a way,
and seeing how it fits in the overall big-picture across the whole
project.

Then, requesting changes also takes time: explaining what has to be
changed, why it has to be changed, and how it has to be changed also
takes time.

So, I would also like to emphasize that contributing is not only about
sending patches; it is also about reviewing and testing the patches of
others, and such contributions are dearly needed.

When a patch is technically ready, the review can range from the laconic
"reviewed-by", which means just that, up to complementing the commit log
with additional details and explanations, which means that the problem
and solution have been fully assessed.

Now for a personal comment: my pet-peeve are commit logs that just
describe the patch; I usually don't need that, except in very complex
patches. What I really need is a commit log that explains the patch,
that tells me the why, not the how.

Of course, finding the right balance between "not enough details" and
"too many details" is not trivial, and is an exercise in its own right.

But again, I do appreciate that people are concerned enough about the
project, and call on the maintainers.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



More information about the buildroot mailing list