Same here, two committers should be enough. El jue, 21 sept 2023 a las 15:23, Jason Porter (<[email protected]>) escribió:
> +1 to just to reviewers, doesn’t need to be a PPMC > > -- > Jason Porter > Software Engineer > He/Him/His > > IBM > > > From: Alex Porcelli <[email protected]> > Date: Wednesday, September 20, 2023 at 17:53 > To: [email protected] <[email protected]> > Subject: [EXTERNAL] Re: [PROPOSAL] Policy for code changes > 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] > > > > > > > > > > > > > >
