"we are doing a CVE+" -> "we might do a CVE+"

On Fri, Dec 24, 2021, 09:19 Gary Gregory <[email protected]> wrote:

> 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]
>> >
>>
>

Reply via email to