ers, doesn’t need to be a PPMC
> >
> > --
> > Jason Porter
> > Software Engineer
> > He/Him/His
> >
> > IBM
> >
> >
> > From: Alex Porcelli
> > Date: Wednesday, September 20, 2023 at 17:53
> > To: dev@kie.apache.org
> > Subjec
dnesday, September 20, 2023 at 17:53
> To: dev@kie.apache.org
> 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
+1 to just to reviewers, doesn’t need to be a PPMC
--
Jason Porter
Software Engineer
He/Him/His
IBM
From: Alex Porcelli
Date: Wednesday, September 20, 2023 at 17:53
To: dev@kie.apache.org
Subject: [EXTERNAL] Re: [PROPOSAL] Policy for code changes
Ricardo,
Here in Apache there is no concept
+1
El jue, 21 sept 2023, 13:12, ricardo zanini fernandes <
ricardozan...@gmail.com> escribió:
> 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
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,
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
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
+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
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] -
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
: [PROPOSAL] Policy for code changes
Thank you for the feedback, Chris.
We're trying to strike a balance between moving to a new home and
disrupting as little as possible the well established projects.
On Thu, Sep 14, 2023 at 4:31 AM Christofer Dutz
wrote:
>
> Hi all,
>
> let me leav
event all
> sorts of problems from happening up-front.
>
> Everything is under version control, we can always revert a bad commit.
>
> Chris
>
> Von: Jason Porter
> Datum: Mittwoch, 13. September 2023 um 21:57
> An: dev@kie.apache.org
> Betreff: Re: [PROPOSAL] Policy for
Datum: Mittwoch, 13. September 2023 um 21:57
> An: dev@kie.apache.org
> Betreff: Re: [PROPOSAL] Policy for code changes
> This looks good, Alex. I’m happy with it. As you have mentioned in gchat,
> we can enforce some of these things by using the `.asf.yaml` file for
> GitHub[1]. I think
all sorts
of problems from happening up-front.
Everything is under version control, we can always revert a bad commit.
Chris
Von: Jason Porter
Datum: Mittwoch, 13. September 2023 um 21:57
An: dev@kie.apache.org
Betreff: Re: [PROPOSAL] Policy for code changes
This looks good, Alex. I’m happy
/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features
--
Jason Porter
Software Engineer
He/Him/His
IBM
From: Alex Porcelli
Date: Wednesday, September 13, 2023 at 11:26
To: dev@kie.apache.org
Subject: [EXTERNAL] [PROPOSAL] Policy for code changes
As we finally transition the codebase
As we finally transition the codebase to the Apache Foundation [1], I
think it's also essential to establish some process over code changes;
based on that, here is a proposal:
1. No Direct Commits: Direct commits to our repositories are
discouraged to maintain consistency and enhance
16 matches
Mail list logo
