[DISCUSS] 1.10.2 release with reload4j

[Christopher <ct...@apache.org>]

I'm interested in putting together a 1.10.2 release with the changes in
https://github.com/apache/accumulo/pull/2458 so that the 1.10 line no
longer requires log4j1, which has several vulnerabilities. Reload4j was
created as a fork from log4j1 from Apache by its original author in order
to provide a transition away from the CVE-riddled log4j1 jars.

I'm sure we have a couple of other small bugfixes and improvements in 1.10
that could benefit from being released as well.

If there are any objections or last-minute tweaks that should be included
in 1.10.2, please discuss here.

Thanks,
Christopher

Re: [DISCUSS] 1.10.2 release with reload4j

[Christopher <ct...@apache.org>]

If those changes are tested and ready to go for 1.10, I don't have a
problem including them. However, from what I understand, they need some
additional testing/polishing. I wouldn't want that to hold up this release.
We could easily include them in the next (1.10.3) if they are ready after
this though.

On Fri, Feb 4, 2022 at 12:36 PM Michael Wall <mj...@gmail.com> wrote:

> I have some GC fixes I am working on that I would like to get into the
> 1.10.2 release.
>
> https://github.com/apache/accumulo/issues/1377
> https://github.com/apache/accumulo/issues/2322
>
> On Thu, Feb 3, 2022 at 4:25 PM Christopher <ct...@apache.org> wrote:
> >
> > That PR adds a new feature that is currently forward-incompatible in
> > behavior with 1.10.0 and 1.10.1. New features are supposed to go into the
> > next release, not patched into a bugfix on a release line that is
> intended
> > to be stable long term.
> >
> > While our semver and LTM guidelines are just guidelines, and we can break
> > them when we want/need to, I think the project is better served if that
> > were rare. Every time we stretch/break those guidelines, we normalize
> > violating them, and the resulting reduced confidence in our software's
> > stability can create a feedback loop where the instability creates
> upgrade
> > aversion, and the upgrade aversion increases the demand for backporting
> > features. That's not sustainable, and it creates an unnecessary burden on
> > the development side of things. I think having boundaries that resist
> > against backporting features to stable branches creates a healthier
> > relationship between the devs and the users.
> >
> > At this point, I'm a "soft" (not yet a veto) -1 to including that in
> 1.10.
> > I could be convinced if it were A) 100% forward compatible with
> > 1.10.0/1.10.1 *and* either B) there was greater consensus for it among
> the
> > PMC or C) a good argument was made to justify adding the feature to a
> patch
> > release [A&(B|C)].
> >
> > As for the schedule, I was thinking about creating a release candidate on
> > Monday if there weren't any issues.
> >
> >
> > On Thu, Feb 3, 2022 at 2:56 PM Dave Marion <dm...@gmail.com> wrote:
> >
> > > I'd like to try and include
> https://github.com/apache/accumulo/pull/2221.
> > > A
> > > little more testing needs to be done, do you have a schedule for the
> 1.10.2
> > > release?
> > >
> > > On Thu, Feb 3, 2022 at 1:55 PM Christopher <ct...@apache.org>
> wrote:
> > >
> > > > I'm interested in putting together a 1.10.2 release with the changes
> in
> > > > https://github.com/apache/accumulo/pull/2458 so that the 1.10 line
> no
> > > > longer requires log4j1, which has several vulnerabilities. Reload4j
> was
> > > > created as a fork from log4j1 from Apache by its original author in
> order
> > > > to provide a transition away from the CVE-riddled log4j1 jars.
> > > >
> > > > I'm sure we have a couple of other small bugfixes and improvements in
> > > 1.10
> > > > that could benefit from being released as well.
> > > >
> > > > If there are any objections or last-minute tweaks that should be
> included
> > > > in 1.10.2, please discuss here.
> > > >
> > > > Thanks,
> > > > Christopher
> > > >
> > >
>

Re: [DISCUSS] 1.10.2 release with reload4j

[Michael Wall <mj...@gmail.com>]

I have some GC fixes I am working on that I would like to get into the
1.10.2 release.

https://github.com/apache/accumulo/issues/1377
https://github.com/apache/accumulo/issues/2322

On Thu, Feb 3, 2022 at 4:25 PM Christopher <ct...@apache.org> wrote:
>
> That PR adds a new feature that is currently forward-incompatible in
> behavior with 1.10.0 and 1.10.1. New features are supposed to go into the
> next release, not patched into a bugfix on a release line that is intended
> to be stable long term.
>
> While our semver and LTM guidelines are just guidelines, and we can break
> them when we want/need to, I think the project is better served if that
> were rare. Every time we stretch/break those guidelines, we normalize
> violating them, and the resulting reduced confidence in our software's
> stability can create a feedback loop where the instability creates upgrade
> aversion, and the upgrade aversion increases the demand for backporting
> features. That's not sustainable, and it creates an unnecessary burden on
> the development side of things. I think having boundaries that resist
> against backporting features to stable branches creates a healthier
> relationship between the devs and the users.
>
> At this point, I'm a "soft" (not yet a veto) -1 to including that in 1.10.
> I could be convinced if it were A) 100% forward compatible with
> 1.10.0/1.10.1 *and* either B) there was greater consensus for it among the
> PMC or C) a good argument was made to justify adding the feature to a patch
> release [A&(B|C)].
>
> As for the schedule, I was thinking about creating a release candidate on
> Monday if there weren't any issues.
>
>
> On Thu, Feb 3, 2022 at 2:56 PM Dave Marion <dm...@gmail.com> wrote:
>
> > I'd like to try and include https://github.com/apache/accumulo/pull/2221.
> > A
> > little more testing needs to be done, do you have a schedule for the 1.10.2
> > release?
> >
> > On Thu, Feb 3, 2022 at 1:55 PM Christopher <ct...@apache.org> wrote:
> >
> > > I'm interested in putting together a 1.10.2 release with the changes in
> > > https://github.com/apache/accumulo/pull/2458 so that the 1.10 line no
> > > longer requires log4j1, which has several vulnerabilities. Reload4j was
> > > created as a fork from log4j1 from Apache by its original author in order
> > > to provide a transition away from the CVE-riddled log4j1 jars.
> > >
> > > I'm sure we have a couple of other small bugfixes and improvements in
> > 1.10
> > > that could benefit from being released as well.
> > >
> > > If there are any objections or last-minute tweaks that should be included
> > > in 1.10.2, please discuss here.
> > >
> > > Thanks,
> > > Christopher
> > >
> >

Re: [DISCUSS] 1.10.2 release with reload4j

[Christopher <ct...@apache.org>]

That PR adds a new feature that is currently forward-incompatible in
behavior with 1.10.0 and 1.10.1. New features are supposed to go into the
next release, not patched into a bugfix on a release line that is intended
to be stable long term.

While our semver and LTM guidelines are just guidelines, and we can break
them when we want/need to, I think the project is better served if that
were rare. Every time we stretch/break those guidelines, we normalize
violating them, and the resulting reduced confidence in our software's
stability can create a feedback loop where the instability creates upgrade
aversion, and the upgrade aversion increases the demand for backporting
features. That's not sustainable, and it creates an unnecessary burden on
the development side of things. I think having boundaries that resist
against backporting features to stable branches creates a healthier
relationship between the devs and the users.

At this point, I'm a "soft" (not yet a veto) -1 to including that in 1.10.
I could be convinced if it were A) 100% forward compatible with
1.10.0/1.10.1 *and* either B) there was greater consensus for it among the
PMC or C) a good argument was made to justify adding the feature to a patch
release [A&(B|C)].

As for the schedule, I was thinking about creating a release candidate on
Monday if there weren't any issues.


On Thu, Feb 3, 2022 at 2:56 PM Dave Marion <dm...@gmail.com> wrote:

> I'd like to try and include https://github.com/apache/accumulo/pull/2221.
> A
> little more testing needs to be done, do you have a schedule for the 1.10.2
> release?
>
> On Thu, Feb 3, 2022 at 1:55 PM Christopher <ct...@apache.org> wrote:
>
> > I'm interested in putting together a 1.10.2 release with the changes in
> > https://github.com/apache/accumulo/pull/2458 so that the 1.10 line no
> > longer requires log4j1, which has several vulnerabilities. Reload4j was
> > created as a fork from log4j1 from Apache by its original author in order
> > to provide a transition away from the CVE-riddled log4j1 jars.
> >
> > I'm sure we have a couple of other small bugfixes and improvements in
> 1.10
> > that could benefit from being released as well.
> >
> > If there are any objections or last-minute tweaks that should be included
> > in 1.10.2, please discuss here.
> >
> > Thanks,
> > Christopher
> >
>

Re: [DISCUSS] 1.10.2 release with reload4j

[Dave Marion <dm...@gmail.com>]

I'd like to try and include https://github.com/apache/accumulo/pull/2221. A
little more testing needs to be done, do you have a schedule for the 1.10.2
release?

On Thu, Feb 3, 2022 at 1:55 PM Christopher <ct...@apache.org> wrote:

> I'm interested in putting together a 1.10.2 release with the changes in
> https://github.com/apache/accumulo/pull/2458 so that the 1.10 line no
> longer requires log4j1, which has several vulnerabilities. Reload4j was
> created as a fork from log4j1 from Apache by its original author in order
> to provide a transition away from the CVE-riddled log4j1 jars.
>
> I'm sure we have a couple of other small bugfixes and improvements in 1.10
> that could benefit from being released as well.
>
> If there are any objections or last-minute tweaks that should be included
> in 1.10.2, please discuss here.
>
> Thanks,
> Christopher
>