Re: Putting a ribbon around 2.14.1?

Volkan, Thank you very much! Tim On Wed, Feb 3, 2021 at 11:55 AM Volkan Yazıcı wrote: > Took some time, but managed to get it merged (with succeeding tests) into > master. > > On Wed, Feb 3, 2021 at 8:39 PM Tim Perry wrote: > > > Ideally, yes, but I haven't done anything to test it on master

Re: Putting a ribbon around 2.14.1?

Took some time, but managed to get it merged (with succeeding tests) into master. On Wed, Feb 3, 2021 at 8:39 PM Tim Perry wrote: > Ideally, yes, but I haven't done anything to test it on master yet. I was > expecting to send a separate pull request for that. If you can merge it, > please do. If

Re: Putting a ribbon around 2.14.1?

Ideally, yes, but I haven't done anything to test it on master yet. I was expecting to send a separate pull request for that. If you can merge it, please do. If you want me to submit a PR, please let me know. On Wed, Feb 3, 2021 at 11:31 AM Volkan Yazıcı wrote: > Resolved merge conflicts and reb

Re: Putting a ribbon around 2.14.1?

Resolved merge conflicts and rebased onto release-2.x branch. Is this also supposed to be applied to master too? On Wed, Feb 3, 2021 at 6:58 PM Matt Sicker wrote: > Go ahead, Volkan. Thanks! > > On Wed, 3 Feb 2021 at 11:46, Volkan Yazıcı > wrote: > > > > Matt, if you approve the changes, I can

Re: Putting a ribbon around 2.14.1?

Go ahead, Volkan. Thanks! On Wed, 3 Feb 2021 at 11:46, Volkan Yazıcı wrote: > > Matt, if you approve the changes, I can also merge them in a couple of > hours. > > On Wed, 3 Feb 2021, 17:44 Matt Sicker wrote: > > > Yes, I'll make sure that it is merged in time for that. > > > > On Wed, 3 Feb 202

Re: Putting a ribbon around 2.14.1?

Matt, if you approve the changes, I can also merge them in a couple of hours. On Wed, 3 Feb 2021, 17:44 Matt Sicker wrote: > Yes, I'll make sure that it is merged in time for that. > > On Wed, 3 Feb 2021 at 10:43, Tim Perry wrote: > > > > Is it possible to merge PR 463 for LOG4J-2624 and LOG4J-

Re: Putting a ribbon around 2.14.1?

Great! Thank you. On Wed, Feb 3, 2021 at 8:44 AM Matt Sicker wrote: > Yes, I'll make sure that it is merged in time for that. > > On Wed, 3 Feb 2021 at 10:43, Tim Perry wrote: > > > > Is it possible to merge PR 463 for LOG4J-2624 and LOG4J-1606 for 2.14.1? > > > > On Wed, Feb 3, 2021 at 2:09 AM

Re: Putting a ribbon around 2.14.1?

Yes, I'll make sure that it is merged in time for that. On Wed, 3 Feb 2021 at 10:43, Tim Perry wrote: > > Is it possible to merge PR 463 for LOG4J-2624 and LOG4J-1606 for 2.14.1? > > On Wed, Feb 3, 2021 at 2:09 AM Volkan Yazıcı > wrote: > > > The LOG4J2-2973 fix is there for both master and rele

Re: Putting a ribbon around 2.14.1?

Is it possible to merge PR 463 for LOG4J-2624 and LOG4J-1606 for 2.14.1? On Wed, Feb 3, 2021 at 2:09 AM Volkan Yazıcı wrote: > The LOG4J2-2973 fix is there for both master and release-2.x branches – > thanks to Fabio Ricchiuti! > I will really appreciate it if somebody can get the 2.14.1 out of

Re: Procedure on accepting GitHub PRs

I'd just try to be careful about introducing unnecessary friction for small contributions. I've never contributed to the FSF or GNU despite being a big fan of their philosophy due to the even more complicated paperwork required to submit anything to them (copyright assignment). On Wed, 3 Feb 2021

Re: Procedure on accepting GitHub PRs

I wonder if we could give ourselves guidelines like: - any change to an algorithm is not trivial (I know, i know, every line of code can be considered an algorithm) - any change created by a tool is trivial, like clean ups that remove trailing whitespace, reflectors code and so on. The issue is th

Re: Procedure on accepting GitHub PRs

It has more to do with copyright. Trivial changes aren't copyrightable or can be trivially verified to be public domain or similar. Think things like typos, one-liners, etc. If you merge a PR from someone without an ICLA, basically, you're taking the responsibility of saying "I verified this code

Re: Procedure on accepting GitHub PRs

I guess the answer is, “You know it when you see it”. Usually it is pretty obvious. I wouldn’t go solely by lines of code, but that could be a factor. I think the way I would view it is if you look at the PR and can review it in a couple of minutes and say to yourself, “Gee, that looks pretty

Re: Procedure on accepting GitHub PRs

Would you briefly define *non-trivial changes*, please? I can imagine it might be difficult to come up with a precise definition, though I would like to hear one. Is it measured by LoC changes? If so, that is a pretty objective criteria. Is it measured by the impact? If so, that is a pretty subject

Re: Procedure on accepting GitHub PRs

ICLAs are needed from people who contribute non-trivial changes and haven't already filled one out. There's a list of names who already submitted ICLAs on this page: https://home.apache.org/unlistedclas.html On Wed, 3 Feb 2021 at 08:17, Volkan Yazıcı wrote: > > Hello, > > Recently we have request

Procedure on accepting GitHub PRs

Hello, Recently we have requested a signed ICLA from Tim Perry for his work available at GitHub PR #463 addressing LOG4J2-1606 and LOG4J2-2624. That said, there have been occasions of me merging PRs from individuals without requesting a signed IC

Re: Putting a ribbon around 2.14.1?

The LOG4J2-2973 fix is there for both master and release-2.x branches – thanks to Fabio Ricchiuti! I will really appreciate it if somebody can get the 2.14.1 out of the door. On Thu, Jan 28, 2021 at 12:02 PM Volkan Yazıcı wrote: > For 2.14.1, would you wait for the resolution of LOG4J2-2973 >