The quick turnaround time for PR reviews is important when I only have time to
work on the project one or two days a week.
> On Sep 18, 2024, at 08:38, Ralph Goers wrote:
>
> I sort of agree and sort of not. It would be nice to have automation that can
> enforce some rules. You can’t do that i
I sort of agree and sort of not. It would be nice to have automation that can
enforce some rules. You can’t do that if there are none.
We could agree in principle to a small number of files and lines but set the
enforcement to a larger number to allow for some exceptions. For example, if we
agr
This proposal is two pages (on my phone)! I can't imagine counting lines
and walking through these steps, it's crazy making IMO. How would you count
lines anyway? From diff output?
I'd rather skip the bikeshedding and let devs create PRs when they think it
makes sense. IOW, when they want a review
On Wed, Sep 18, 2024 at 10:17 AM Piotr P. Karwasz
wrote:
> However, we don't necessarily need to use `2.x` or `main` for those tests.
>
You cannot fix fuzz tests in another branch than `2.x` once OSS-Fuzz starts
pointing there – unless you're willing to waste +2 months for testing a
simple typo:
Hi Volkan,
On Wed, 18 Sept 2024 at 09:46, Volkan Yazıcı wrote:
> Changes can be exempt from this policy if and only if they suffice *only
> one* of the following conditions:
>
>1. Grammatical corrections to the documentation (incl. Javadoc and
>release notes)
>2. Code typo fixes¹ less
I agree in principle, but...
*Exemption criteria*
I agree with Ralph on that we should specify criteria on what shall be
exempt from this PR-driven workflow policy. We should of course materialize
these criteria collaboratively. Below is my attempt for a starting point:
Changes can be exempt fro
This isn’t a vote so I am not going to. If I had to vote I wouldn’t vote for a
policy that requires RTC always. However, I would vote for a policy that
requires RTC when specified criteria are met.
Ralph
> On Sep 17, 2024, at 10:28 AM, Ralph Goers wrote:
>
> First, the obvious. I haven’t comm
I'm with Matt. It should be left at the discretion of the developer whether
a PR or straight commit is justified. I see no reason to throw sand in the
gears.
Gary
On Tue, Sep 17, 2024, 2:05 PM Matt Sicker wrote:
> I’m -1 on switching to RTC. Same reason as always. Losing momentum from
> waiting
Hi
we have only had good experiences with RTC in log4net.
Of course, a lot depends on a review being done in a timely manner.
The feedback is always valuable and I can apply the changes before merging to
main.
But most of the time, a pending review does not stop me from continuing my work.
Either
Hi Matt,
On Tue, 17 Sept 2024 at 20:06, Matt Sicker wrote:
>
> I’m -1 on switching to RTC. Same reason as always. Losing momentum from
> waiting for an unnecessary code review will simply lead to much longer gaps
> between time I spend on the project.
Honestly, momentum is not always a good th
Hello,
After working on Log4j with PRs, I have changed my opinion on CTR/RTC in this
case. Previously, I would have said keep CTR. However, I worked with RTC using
PRs, and my experiences were not bad. I was a bit lost with the comments on the
PR, but I figured it out somehow. I think GitHub is
I’m -1 on switching to RTC. Same reason as always. Losing momentum from waiting
for an unnecessary code review will simply lead to much longer gaps between
time I spend on the project.
> On Sep 17, 2024, at 03:30, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Inspired by the way the Log4Net team wo
First, the obvious. I haven’t committed much in a while. The last several I did
I used PRs primarily because it makes it easier for people to review the
changes but I didn’t necessarily wait for a review. For really simple stuff
I've never use a PR. However, with the switch from Jira to GitHub
Maybe we should talk about net vs. J separately?
Gary
On Tue, Sep 17, 2024, 10:53 AM Piotr P. Karwasz
wrote:
> Hi Ralph,
>
> On Tue, 17 Sept 2024 at 15:47, Ralph Goers
> wrote:
> >
> > Why? i.e. - what currently isn’t working?
>
> I merely wish to formalize what is already happening and set up
Hi Ralph,
On Tue, 17 Sept 2024 at 15:47, Ralph Goers wrote:
>
> Why? i.e. - what currently isn’t working?
I merely wish to formalize what is already happening and set up a
branch protection rule to enforce it.
Note that I have never seen a PR in Log4Net being merged without a review.
On the ot
Why? i.e. - what currently isn’t working?
Ralph
> On Sep 17, 2024, at 1:30 AM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Inspired by the way the Log4Net team works, I would like to propose a
> switch from our CTR policy to RTC:
>
> * every change to the main branches should go through a pull re
Hi all,
Inspired by the way the Log4Net team works, I would like to propose a
switch from our CTR policy to RTC:
* every change to the main branches should go through a pull request,
* pull requests can be merged if they have 1 positive review and no
requested changes. To allow everyone to look a
17 matches
Mail list logo
