Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]

[via GitHub]

GitHub user rgoers added a comment to the discussion: Is using %uuid{RANDOM} 
pattern in JsonTemplateLayout considered garbage-free?

I hate to disagree Piotr, but our time based uuid exists for exactly this use 
case. It will provide a unique value across all servers. While it isn’t going 
to be unique forever, the length of time it is guaranteed to be unique should 
be sufficient for virtually any use case.

GitHub link: 
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12749819


This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org

[RESULT] [VOTE] Add branch protection rules to Log4j

[Piotr P. Karwasz]

Hi,

These are my votes:


On 2.04.2025 19:12, Piotr P. Karwasz wrote:

Vote 1. Require a pull request before merging:
[ ] +1, enable this feature
[ ] -1, do not enable this feature

+1


Vote 2. Require conversation resolution before merging:
[ ] +1, enable this feature
[ ] -1, do not enable this feature


+1


Vote 3. Require linear history (Prevent merge commits from being 
pushed to code branches. Only "Squash" and similar allowed):

[ ] +1, enable this feature
[ ] -1, do not enable this feature


+0: I do like linear history, but in some situations (like merging a 
bigger feature branch) it is just safer to do a merge instead of rebasing.


Note: for smaller feature branches I prefer rebasing.


Vote 4. Require status checks to pass before merging:
[ ] +1, enable this feature
[ ] -1, do not enable this feature


+1 and I'll work on flaky tests to make that easier.



Vote 5. Require at least one positive review before merging:
[ ] +1, enable this feature
[ ] -1, do not enable this feature


+1 and I hope enough people will start reviewing.


With this the result of the vote is:

Vote 1. Require a pull request before merging:

+4 (+1 from Jan, Ralph, Volkan and me, Gary abstained)

Vote 2. Require conversation resolution before merging:

+4 (+1 from Jan, Ralph, Volkan and me, Gary abstained)

Vote 3. Require linear history:

-0.9 (+1 from Volkan, -0.9 from Jan, -1 from Gary, Ralph and me abstained)

Vote 4. Require status checks to pass before merging:

+4 (+1 from Jan, Ralph, Volkan and me, Gary abstained)

Vote 5. Require at least one positive review before merging:

+2.5 (+1 from Jan, Volkan and me, -0.5 from Ralph, Gary abstained)


I will proceed implementing via PRs rules 1, 2, 4 and 5. It goes without 
saying, somebody needs to review them.


Piotr