Hi guys, I agree with the triaging needed to be added to quite a lot of people actually. For example from the Red Hat QE team almost nobody (just 2 out of 10+ people) is among the committers (despite significant code contributions over the past years). On the other hand, from the engineers, almost everybody has commit rights. This means that a majority of those QE contributors don't have the ability to add reviewers to their PRs, nor will they be able to even trigger/retrigger the PR checks. This really slows down their work.
So I am suggesting 2 things: 1. Extend the list of committers by some other members of that team. 2. Add remaining members to the .asf.yaml files in the repositories so they have the ability to add reviewers and trigger/retrigger the PR checks. As an example, here is the kafka .asf.yaml file with such a setup: https://github.com/apache/kafka/blob/trunk/.asf.yaml You can see there are 2 sections: - github_whitelist - for triggering builds on pull requests - collaborators - for triaging pull requests Without changes like these the work of the QE team may be slowed down quite seriously. Thanks. Marian Macik On Thursday, 21 September 2023 at 08:12 -0300, ricardo zanini fernandes wrote: > Alex, > > Thanks for the update! I think it’s reasonable to have 2 commiters. > Let’s > hear from others then. > > About the automation, we can reuse something for basic requirements. > I > think codeowners file is a good first step and GH automatically adds > people > there in every PR review. So no need to triage, or automation for > this > task. > > If everyone agrees, we can come up with a spreadsheet, or doc, or a > policy > listing these people and the respective projects. > > Otherwise I believe a simple “add reviewer action/bot” from GH can do > the trick. > > Cheers! > > On Wed, 20 Sep 2023 at 8:53 PM Alex Porcelli <[email protected]> > wrote: > > > Ricardo, > > > > Here in Apache there is no concept of component leadership, it’s a > > flat > > structure that is basically [P]PMC and Committers. > > > > I’m ok to adjust for 2 committers for now. Would love to hear from > > others > > here if we got the consensus that it’s expected. > > > > In regard triage, there’s an option with .asf.yaml to have up to 10 > > users > > for triage. > > > > About the use of bots, any automation is more than welcome. However > > this > > needs to be developed and properly maintained. So I suggest to open > > a new > > email thread to discuss such topic. > > > > Alex > > > > On Wed, Sep 20, 2023 at 2:16 PM ricardo zanini fernandes < > > [email protected]> wrote: > > > > > +1 to what Mario just said. I was about to send the same email. > > > > > > For instance, at this moment I have 4 PRs waiting to be merged > > > and with > > all > > > honesty, a PPMC will only give his "ok". So it's just a waste of > > > their > > > time. Eder suggested having leads in each component, which makes > > > a bit > > more > > > sense. Or just what you suggested, Alex: 2 commuters. We can > > > adjust as we > > > go. > > > > > > The other point is that we should also have a group for triage or > > > have a > > > bot to set reviewers automatically (via codeowners, maybe?). A > > > few > > > contributors are asking for at least triage/resolve comments > > > permissions. > > > Is that possible? > > > > > > Cheers! > > > -- > > > Ricardo Zanini Fernandes > > > Vida longa e próspera. > > > > > > > > > On Wed, Sep 20, 2023 at 2:12 PM Alex Porcelli > > > <[email protected]> > > wrote: > > > > > > > Mario, > > > > > > > > I think you have a very valid point, and I think this could be > > > > adjusted > > > by > > > > 2 committers. Another thing that we could take advantage in the > > > > future > > > is, > > > > giving the diverse and complex codebase, use codeowners [1] and > > > > balance > > > > better the code review among all the committers. > > > > > > > > [1] - > > > > > > > > > > > > > https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners > > > > > > > > Regards, > > > > Alex > > > > > > > > On Wed, Sep 20, 2023 at 12:32 PM Mario Fusco > > > > <[email protected]> > > > > wrote: > > > > > > > > > Hi Alex, > > > > > > > > > > Sorry if I'm reading and replying to this email with so much > > > > > delay. > > > > > > > > > > > • The other is from a PPMC member. > > > > > > > > > > In all honesty this specific constraint seems unnecessarily > > > > > and > > > > > excessively restrictive to me. I'm afraid that waiting for an > > approval > > > > from > > > > > a so small group of persons for all the pull requests in all > > > > > kie > > > projects > > > > > could become a serious bottleneck. In this way we may have > > > > > pending > > pull > > > > > requests waiting for weeks or months. > > > > > > > > > > The other point of attention is that the whole kie codebase > > > > > is quite > > > huge > > > > > and diverse. There could be no more than one person in the > > > > > PPMC group > > > > with > > > > > the right competences to give an informed opinion on a > > > > > specific pull > > > > > request. Or in some cases not even that one. Who will review > > > > > an > > > operator > > > > > written in Go? And even for the core part of Drools (which of > > > > > course > > is > > > > my > > > > > main concern) there could be only Mark to have an idea on how > > > > > to > > > review a > > > > > pull request. And in some specific newer parts like the > > > > > reliable > > > session > > > > or > > > > > the Quarkus integration maybe not even him. > > > > > > > > > > Do you have any opinion on this? > > > > > > > > > > Thanks for feedback, > > > > > Mario > > > > > > > > > > ------------------------------------------------------------- > > > > > -------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
