Hi Volkan, Nothing is ideal or great about a Log4j1 revival IMO. I still see more cons than pros. I understand that some people choose to stay stuck on it despite the 2015 EOL marker. I wish I'd joined that debate club in high school so I could better articulate my arguments for pulling these folks of the Log4j 1 doldrums.
So, speaking of not ideal, we might consider EOL'ing the old repo itself and saying you have x months to move your stuff, the component is EOL after all and will remain so even though we are doing a CVE+ release (CVE + the 2.x kind of changes that are not 1.x CVEs) from the new repo. A new repo will make people think about what PRs matter and what is throwaway or just cruft. It might make things less confusing for GitHub visitors that find a new repo that is not full of old stuff that will never come to life, EOL after all. It's not ideal but neither is using dead EOL software. Gary On Fri, Dec 24, 2021, 03:21 Volkan Yazıcı <[email protected]> wrote: > Gary, I see that you want to stick to the `logging-log4j1` repo Ralph has > created. What do you propose for the current `log4j` repo? Will they exist > next to each other? I think that will be a really confusing setup. Can we > make a pointer from `log4j` to `logging-log4j` in the README and GitHub > description? > > I agree with stating the goal clearly. > > I don't think we will be able to avoid PRs contributing random stuff to > Log4j. Once we make a 1.2.18 release, Pandora's box will be open. The only > thing we can do from then on is to share the goal statement with the > incoming PRs and simply reject them. > > On Thu, Dec 23, 2021 at 10:50 PM Gary Gregory <[email protected]> > wrote: > > > -1 > > We just created logging-log4j1 and converted the SVN repo into it, let's > > stick to that. I even made a commit ;-) > > I claim it is a good thing to start with a new repo because it creates a > > tiny bit of friction, for a project that is still End-of-Life after all. > > Even if it is a bit of friction to bring in old stuff from the old repo, > > this would provide a kind of effort/value filter. > > The concurrent consensus I see on the PMC is to fix the one listed CVE on > > our site plus other fixes in the style of the recent 2.x fixes. > > Bringing in all of the cruft from the old repo will give the wrong > > impression that we actually might be merging this or that random fix and > > feature. Which I claim is not the goal here. > > > > I feel we might need an addendum or a subsequent VOTE with a stated goal > or > > charter for this repo to only provide CVE fixes (see above). Projects > > usually have a charter, not components I do not think, but I think we > > should have one here and put it in front and center in the README.md so > we > > can manage expectations for people finding the repo on GitHub. > > > > Gary > > > > On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers <[email protected]> > > wrote: > > > > > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus > has > > > recommended that we can divorce > > > the read-only SVN repo from https://github.com/apache/log4j. However, > it > > > will not be able to keep the same > > > name as all Git repos owned by the logging project must start with > > > “logging-“. > > > > > > So this vote is to: > > > 1. Delete the apache/logging-log4j1 repo I created last night. > > > 2. Divorce the apache/log4j repo from SVN. > > > 3. Rename apache/log4j to apache/logging-log4j1. > > > 4. Create a branch named “main” from the v1_2_17 tag. > > > 5. Make main the default branch in GitHub. > > > > > > While all votes are welcome Infra needs consensus from the PMC on this > > > vote so the result will separate > > > binding from non-binding votes. > > > > > > Ralph > > > > > > PS - I’ve separated this from the previous vote thread since it was > > mostly > > > discussion. If you want to discuss > > > this please prefix the subject with [DISCUSS] > > >
