Re: [VOTE] PIP-166: Function add MANUAL delivery semantics

[Baodi Shi]

The PIP passes with 3 bindings +1: Hang Chen, Penghui Li and Enrico. 

I will start working, @Penghui Li Please help to move to wiki.


Thanks,
Baodi Shi

> On Jun 9, 2022, at 10:2029, Hang Chen  wrote:
> 
> +1 (binding)
> 
> Thanks,
> Hang
> 
> Baodi Shi  于2022年6月8日周三 22:23写道：
>> 
>> Hi, Enrico.
>> 
>> Thank review, I changed it.
>> 
>> 
>> Thanks,
>> Baodi Shi
>> 
>>> On Jun 8, 2022, at 11:3828, PengHui Li  wrote:
>>> 
>>> I have left one last minute comment, can you please take a look ? then
>>> I will post my +1
>> 

?????? [ANNOUNCE] New Committer: Dezhi Liu

[Just do it]

Thank you everyone!
Dezhi




----
??: 
   "dev"

https://github.com/liudezhi2098) to 
become a committer
 and
 we are pleased to announce that he has 
accepted.
 
 Dezhi Liu (with Github id liudezhi2098) 
contributed many
 improvements
 and bug fixes to Pulsar.
 
 Being a committer enables easier contribution 
to the project since
 there is no need to go via the patch 
submission process. This should
 enable better productivity.
 
 Welcome and Congratulations, Dezhi Liu!
 
 Please join us in congratulating and welcoming 
Dezhi Liu onboard!
 
 Best Regards,
 Hang Chen on behalf of the Pulsar PMC
 
 
 
 

Re: [VOTE] PIP-166: Function add MANUAL delivery semantics

[Hang Chen]

+1 (binding)

Thanks,
Hang

Baodi Shi  于2022年6月8日周三 22:23写道：
>
> Hi, Enrico.
>
> Thank review, I changed it.
>
>
> Thanks,
> Baodi Shi
>
> > On Jun 8, 2022, at 11:3828, PengHui Li  wrote:
> >
> > I have left one last minute comment, can you please take a look ? then
> > I will post my +1
>

Re: [DISCUSS] PIP-175: Extend time based release process

[Neng Lu]

1. We can compose some charts/tables as https://endoflife.date/python on
the Pulsar website to help people understand the time frame.

2. Regarding the LTS release proposal, one thing I need some clarification
is will the LTS release include major new features compared to last release?
For example, in the following releases, is 4.0 basically the same as
3.2 except it's supported longer or 4.0 has new major features than 3.2?
3.0 <- LTS
3.1
3.2
4.0 <- LTS


On Wed, Jun 8, 2022 at 4:45 PM Michael Marshall 
wrote:

> > From the code-freeze point, to minimize the risk of delaying the
> > release, only bug fixes involving a regression of behavior compared to
> > a previous release should be allowed. Occasional exceptions will be
> > possible after higher scrutiny of the change.
>
> It's a frequent point of discussion to debate which bug fixes are
> urgent enough to trigger a new RC candidate.
>
> I propose that we try to set guidelines now so that we can rely on
> them when issues come up.
>
> In my opinion, net new bugs that were introduced in the version should
> be fixed. Bugs that are not new, should not trigger a new RC, unless
> there is general consensus (however we define that) that the bug is
> sufficiently bad that we should trigger a new RC.
>
> If a bug is discovered during the RC testing period and it is not
> fixed, we should note this in the release notes for the version under
> a "known issues" section. This way, users of the impacted feature may
> decide to delay upgrading, while users that do not rely on the feature
> will have confidence upgrading. The main goal here is to ensure that
> we don't miss release deadlines, as Matteo just mentioned, and to give
> our users confidence when upgrading.
>
> Performance regressions are another issue that will arise. Dave Fisher
> has been working extensively on building out performance testing
> infrastructure to measure many Pulsar features. I expect that he (or
> someone else doing performance testing) will find degraded performance
> for some feature in the future. I think we should have a general rule
> of thumb that some percent regression (maybe 10%?) is serious enough
> to trigger a new RC. A percent might not be the only measure. If we
> have absolute metrics, like that a Pulsar cluster of x size must be
> able to handle y topics, that might be meaningful, too.
>
> What do others think?
>
> - Michael
>
> On Wed, Jun 8, 2022 at 2:26 PM Matteo Merli 
> wrote:
> >
> > > Schedules always slip. Would you say that if the 3.x feature releases
> take too long with these hypothetical dates that 3.5 would be dropped in
> order to release 4.0 on schedule?
> >
> > Yes, there needs to be clarity for the users on when releases are to
> > be expected, even more so for LTS releases. And while it's true that
> > there are always delays, we have a lot that we can do to try to
> > minimize it. (eg: having a public deadline to hit will help in getting
> > everyone on the same page).
>


-- 
Best Regards,
Neng

Re: [DISCUSS] PIP-175: Extend time based release process

[Michael Marshall]

> From the code-freeze point, to minimize the risk of delaying the
> release, only bug fixes involving a regression of behavior compared to
> a previous release should be allowed. Occasional exceptions will be
> possible after higher scrutiny of the change.

It's a frequent point of discussion to debate which bug fixes are
urgent enough to trigger a new RC candidate.

I propose that we try to set guidelines now so that we can rely on
them when issues come up.

In my opinion, net new bugs that were introduced in the version should
be fixed. Bugs that are not new, should not trigger a new RC, unless
there is general consensus (however we define that) that the bug is
sufficiently bad that we should trigger a new RC.

If a bug is discovered during the RC testing period and it is not
fixed, we should note this in the release notes for the version under
a "known issues" section. This way, users of the impacted feature may
decide to delay upgrading, while users that do not rely on the feature
will have confidence upgrading. The main goal here is to ensure that
we don't miss release deadlines, as Matteo just mentioned, and to give
our users confidence when upgrading.

Performance regressions are another issue that will arise. Dave Fisher
has been working extensively on building out performance testing
infrastructure to measure many Pulsar features. I expect that he (or
someone else doing performance testing) will find degraded performance
for some feature in the future. I think we should have a general rule
of thumb that some percent regression (maybe 10%?) is serious enough
to trigger a new RC. A percent might not be the only measure. If we
have absolute metrics, like that a Pulsar cluster of x size must be
able to handle y topics, that might be meaningful, too.

What do others think?

- Michael

On Wed, Jun 8, 2022 at 2:26 PM Matteo Merli  wrote:
>
> > Schedules always slip. Would you say that if the 3.x feature releases take 
> > too long with these hypothetical dates that 3.5 would be dropped in order 
> > to release 4.0 on schedule?
>
> Yes, there needs to be clarity for the users on when releases are to
> be expected, even more so for LTS releases. And while it's true that
> there are always delays, we have a lot that we can do to try to
> minimize it. (eg: having a public deadline to hit will help in getting
> everyone on the same page).

[DISCUSS] Pulsar Broker Load Balancer Improvement Project

[Heesung Sohn]

Dear Pulsar community,

Our engineers from StreamNative would like to contribute to improving the
broker load balancer.

To collaborate with the community from the early phase, we opened a slack
channel and summarized the improvement ideas in this document.

pulsar slack channel : *#broker-load-balance-improvement-project
*
pulsar broker load balance Improvement area doc


We are looking forward to hearing your feedback.

Regards,
Heesung

[GitHub] [pulsar-helm-chart] rdhabalia opened a new pull request, #269: Support mechanism to provide external zookeeper-server list to build global/configuration zookeeper

[GitBox]

rdhabalia opened a new pull request, #269:
URL: https://github.com/apache/pulsar-helm-chart/pull/269

   Fixes #268
   
   ### Motivation
   Right now, [chart 
dynamically](https://github.com/apache/pulsar-helm-chart/blob/master/charts/pulsar/templates/zookeeper-statefulset.yaml#L140)
 creates zk cluster with zk pods initialized in the same namespace. However, 
for global/configuration zookeeper, user requires to build zk clusters with 
pods deployed in different namespaces. Therefore, user needs a mechanism to 
pass an external list of zk-servers to the chart and build zk-cluster with pods 
across different namespaces.
   
   ### Modification
   - Chart should be considering zk-value's configuration for external 
zookeeper and generate zk-configuration file with appropriate zk-server list 
and unique id of that zookeeper.
   
   This PR sets `ZOOKEEPER_SERVERS` value provided by user and also sets 
override-value flag which will be used by 
[generate-zookeeper-config.sh](https://github.com/apache/pulsar/blob/master/docker/pulsar/scripts/generate-zookeeper-config.sh)
 to override external zk list in config file and assign appropriate id to the 
host.
   
   
   ### Result
   - User can add `ZOOKEEPER_SERVERS` string into `zookeeper.configData` in 
[Values.yaml](https://github.com/apache/pulsar-helm-chart/blob/master/charts/pulsar/values.yaml#L385)
 file to override external zk-server list.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] PIP-175: Extend time based release process

[Matteo Merli]

> Schedules always slip. Would you say that if the 3.x feature releases take 
> too long with these hypothetical dates that 3.5 would be dropped in order to 
> release 4.0 on schedule?

Yes, there needs to be clarity for the users on when releases are to
be expected, even more so for LTS releases. And while it's true that
there are always delays, we have a lot that we can do to try to
minimize it. (eg: having a public deadline to hit will help in getting
everyone on the same page).

Re: [DISCUSS] PIP-175: Extend time based release process

[Dave Fisher]

> On Jun 8, 2022, at 11:44 AM, Matteo Merli  wrote:
> 
> On Tue, Jun 7, 2022 at 10:14 PM PengHui Li  wrote:
>> 
>> I'm not sure I fully understand the LTS release and feature release.
>> 
>>> The LTS releases will be identified by being a `.0` version. For example:
>>> * `3.0` -> LTS
>>> * `3.1` -> regular release
>>> * `3.2` -> regular release
>>> * `4.0` -> LTS
>> 
>> In this example, we can only introduce new features in 3.1 and 3.2,
>> and 3.1.x and 3.2.x should be the patch release based on the feature
>> release?
> 
> Exactly, that aspect won't be changed. I will clarify more in the document.
> 
>> We can have one patch release for a month.
>> 
>> 3.0.x is the LTS release that will support at most three years.
>> After we have 4.0 LTS release, we will still support 3.0.x TLS for at least
>> 18 months.
>> And 4.0 TLS will have all the new features from 3.x
> 
> Correct.
> 
> 
>>> This can be translated into:
>>>  * We support the last 2 LTS releases and the last 2 feature releases
>>>  * Security patches are provided for the past 3 LTS releases and 2
>>> feature releases
>> 
>> Does this mean we can introduce new features in 3.x even if we have 4.x?
>> And how many patch releases for the feature releases we will support,
>> such as 3.1.x, 3.2.x, 3.3.x, 4.1.x, 4.2.x.
>> 
>> I think 2 feature releases means 3.x and 4.x here?
> 
> At the moment when 4.0.0 is released, there won't be any new feature
> release in 3.x.
> 
> Based on the 18months schedules we would have 1 LTS followed by 5
> non-LTS releases (without counting patch releases). There won't be any
> 3.x feature release after 3.5.
> 
> Example using hypothetical dates:
> * Jan 2023 --- 3.0
> * Apr 2023 --- 3.1
> * Jul 2023 --- 3.2
> * Oct 2023 --- 3.3
> * Jan 2024 --- 3.4
> * Apr 2024 --- 3.5
> * Jul 2024 --- 4.0
> * Oct 2024 --- 4.1
> * ….

Schedules always slip. Would you say that if the 3.x feature releases take too 
long with these hypothetical dates that 3.5 would be dropped in order to 
release 4.0 on schedule?

ATB,
Dave

[GitHub] [pulsar-helm-chart] rdhabalia opened a new issue, #268: Support mechanism to provide external zookeeper-server list to build global/configuration zookeeper

[GitBox]

rdhabalia opened a new issue, #268:
URL: https://github.com/apache/pulsar-helm-chart/issues/268

   ### Motivation
   Right now, [chart 
dynamically](https://github.com/apache/pulsar-helm-chart/blob/master/charts/pulsar/templates/zookeeper-statefulset.yaml#L140)
 creates zk cluster with zk pods initialized in the same namespace. However, 
for global/configuration zookeeper, user requires to build zk clusters with 
pods deployed in different namespaces. Therefore, user needs a mechanism to 
pass an external list of zk-servers to the chart and build zk-cluster with pods 
across different namespaces.
   
   ### Modification
   - Chart should be considering zk-value's configuration for external 
zookeeper and generate zk-configuration file with appropriate zk-server list 
and unique id of that zookeeper.
   
   
   ### Result
   - User can add `ZOOKEEPER_SERVERS` string into `zookeeper.configData` in 
[Values.yaml](https://github.com/apache/pulsar-helm-chart/blob/master/charts/pulsar/values.yaml#L385)
 file to override external zk-server list.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] PIP-175: Extend time based release process

[Matteo Merli]

--
Matteo Merli


On Wed, Jun 8, 2022 at 12:33 AM Haiting Jiang  wrote:
>
> >  I was actually not thinking of changing the denomination of 2.11. On
> > one hand, it could make sense for being the first Java 17 release, but
> > on the other, we'd be releasing 2 LTSs super close between each other
> > and we'd have to support 1 release more for the time being.
> >
> > I'd like to hear more opinions here :)
>
> It's a little confusing here, if 2.10 is LTS for being the last Java 8 
> release,
> will there be feature release for 2.10 LTS, and 2.10.x are both feature 
> release and patch release?

When we say 2.10 is LTS, it would mean that we are going to make patch
releases (2.10.1, 2.10.2, ...) with bug fixes and security updates for
a longer period of time. No new features will be added in 2.10.x

Re: [DISCUSS] PIP-175: Extend time based release process

[Matteo Merli]

On Tue, Jun 7, 2022 at 10:14 PM PengHui Li  wrote:
>
> I'm not sure I fully understand the LTS release and feature release.
>
> > The LTS releases will be identified by being a `.0` version. For example:
> > * `3.0` -> LTS
> > * `3.1` -> regular release
> > * `3.2` -> regular release
> > * `4.0` -> LTS
>
> In this example, we can only introduce new features in 3.1 and 3.2,
> and 3.1.x and 3.2.x should be the patch release based on the feature
> release?

Exactly, that aspect won't be changed. I will clarify more in the document.

> We can have one patch release for a month.
>
> 3.0.x is the LTS release that will support at most three years.
> After we have 4.0 LTS release, we will still support 3.0.x TLS for at least
> 18 months.
> And 4.0 TLS will have all the new features from 3.x

Correct.


> > This can be translated into:
> >   * We support the last 2 LTS releases and the last 2 feature releases
> >   * Security patches are provided for the past 3 LTS releases and 2
> > feature releases
>
> Does this mean we can introduce new features in 3.x even if we have 4.x?
> And how many patch releases for the feature releases we will support,
> such as 3.1.x, 3.2.x, 3.3.x, 4.1.x, 4.2.x.
>
> I think 2 feature releases means 3.x and 4.x here?

At the moment when 4.0.0 is released, there won't be any new feature
release in 3.x.

Based on the 18months schedules we would have 1 LTS followed by 5
non-LTS releases (without counting patch releases). There won't be any
3.x feature release after 3.5.

Example using hypothetical dates:
* Jan 2023 --- 3.0
* Apr 2023 --- 3.1
* Jul 2023 --- 3.2
* Oct 2023 --- 3.3
* Jan 2024 --- 3.4
* Apr 2024 --- 3.5
* Jul 2024 --- 4.0
* Oct 2024 --- 4.1
* 

Re: [DISCUSS] PIP-173 : Create a built-in Function implementing the most common basic transformations

[Neng Lu]

I would suggest first having some concrete implementations in a separate
repo.
After verifying its functionality and performance, then we can move into
the main pulsar repo.

On Fri, Jun 3, 2022 at 5:09 AM Enrico Olivelli  wrote:

> Overall I agree with the proposal.
> I left some minor feedback on the issue
>
> Thank you
>
> Enrico
>
> Il giorno gio 2 giu 2022 alle ore 16:57 Christophe Bornet
>  ha scritto:
> >
> > Dear Pulsar community,
> >
> > I opened PIP-173 https://github.com/apache/pulsar/issues/15902 to
> create a
> > built-in Function implementing the most common basic transformations.
> >
> > Let me know what you think.
> >
> > Best regards,
> >
> > Christophe
> >
> > --
> >
> > ## Motivation
> >
> > Currently, when users want to modify the data in Pulsar, they need to
> write
> > a Function.
> > For a lot of use cases, it would be handy for them to be able to use a
> > ready-made built-in Function that implements the most common basic
> > transformations like the ones available in [Kafka Connect’s SMTs](
> >
> https://docs.confluent.io/platform/current/connect/transforms/overview.html
> > ).
> > This removes users the burden of writing the Function themselves, having
> to
> > understanding the perks of Pulsar Schemas, coding in a language that they
> > may not master (probably Java if they want to do advanced stuff), and
> they
> > benefit from battle-tested, maintained, performance-optimised code.
> >
> > ## Goal
> >
> > This PIP is about providing a `TransformFunction` that executes a
> sequence
> > of basic transformations on the data.
> > The `TransformFunction` shall be easy to configure, launchable as a
> > built-in NAR.
> > The `TransformFunction` shall be able to apply a sequence of common
> > transformations in-memory so we don’t need to execute the
> > `TransformFunction` multiple times and read/write to a topic each time.
> >
> > This PIP is not about appending such a Function to a Source or a Sink.
> > While this is the ultimate goal, so we can provide an experience similar
> to
> > Kafka SMTs and avoid a read/write to a topic, this work will be done in a
> > future PIP.
> > It is expected that the code written for this PIP will be reusable in
> this
> > future work.
> >
> > ## API Changes
> >
> > This PIP will introduce a new `transform` module in `pulsar-function`
> > multi-module project.  The produced artifact will be a NAR of the
> > TransformFunction.
> >
> > ## Implementation
> >
> > When it processes a record, `TransformFunction` will :
> >
> > * Create a mutable structure `TransformContext` that contains
> >
> > ```java
> > @Data
> > public class TransformContext {
> > private Context context;
> > private Schema keySchema;
> > private Object keyObject;
> > private boolean keyModified;
> > private Schema valueSchema;
> > private Object valueObject;
> > private boolean valueModified;
> > private KeyValueEncodingType keyValueEncodingType;
> > private String key;
> > private Map properties;
> > private String outputTopic;
> > ```
> >
> > If the record is a `KeyValue`, the key and value schemas and object are
> > unpacked. Otherwise the `keySchema` and `keyObject` are null.
> >
> > * Call in sequence the process method of a series of `TransformStep` on
> > this `TransformContext`
> >
> > ```java
> > public interface TransformStep {
> > void process(TransformContext transformContext) throws Exception;
> > }
> > ```
> >
> > Each `TransformStep` can then modify the `TransformContext` as needed.
> >
> > * Call the `send()` method of the `TransformContext` which will create
> the
> > message to send to the outputTopic, repacking the KeyValue if needed.
> >
> > The `TransformFunction` will read its configuration as Json from
> > `userConfig` in the format:
> >
> > ```json
> > {
> >   "steps": [
> > {
> >   "type": "drop-fields", "fields": "keyField1,keyField2", "part":
> "key"
> > },
> > {
> >   "type": "merge-key-value"
> > },
> > {
> >   "type": "unwrap-key-value"
> > },
> > {
> >   "type": "cast", "schema-type": "STRING"
> > }
> >   ]
> > }
> > ```
> >
> > Each step is defined by its `type` and uses its own arguments.
> >
> > This example config applied on a KeyValue input record with
> > value `{key={keyField1: key1, keyField2: key2, keyField3: key3},
> > value={valueField1: value1, valueField2: value2, valueField3: value3}}`
> > will give after each step:
> > ```
> > {key={keyField1: key1, keyField2: key2, keyField3: key3},
> > value={valueField1: value1, valueField2: value2, valueField3:
> > value3}}(KeyValue)
> >|
> >| ”type": "drop-fields", "fields": "keyField1,keyField2”,
> > "part": "key”
> >|
> > {key={keyField3: key3}, value={valueField1: value1, valueField2: value2,
> > valueField3: value3}} (KeyValue)
> >|
> >| "type": "merge-key-value"
> >|
> > {key={keyField3: key3}, value={keyField3: key3, 

[GitHub] [pulsar-site] michaeljmarshall commented on pull request #104: fix build script about crowdin

[GitBox]

michaeljmarshall commented on PR #104:
URL: https://github.com/apache/pulsar-site/pull/104#issuecomment-1150077264

   @urfreespace - can you describe the problem you are fixing here? This PR was 
merged without any helpful description. Thanks.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [VOTE] PIP-166: Function add MANUAL delivery semantics

[Baodi Shi]

Hi, Enrico.

Thank review, I changed it.


Thanks,
Baodi Shi

> On Jun 8, 2022, at 11:3828, PengHui Li  wrote:
> 
> I have left one last minute comment, can you please take a look ? then
> I will post my +1

Re: [VOTE] PIP-166: Function add MANUAL delivery semantics

[Enrico Olivelli]

+1 (binding)

Enrico

Il giorno mer 8 giu 2022 alle ore 05:39 PengHui Li
 ha scritto:
>
> +1
>
> Penghui
> On Jun 8, 2022, 09:32 +0800, Rui Fu , wrote:
> > +1
> >
> > Best,
> >
> > Rui Fu
> > 在 2022年6月8日 +0800 04:51，Neng Lu ，写道：
> > > Hi All,
> > >
> > > +1 (non-binding)
> > >
> > > On Tue, Jun 7, 2022 at 5:42 AM Enrico Olivelli  
> > > wrote:
> > >
> > > > I have left one last minute comment, can you please take a look ? then
> > > > I will post my +1
> > > >
> > > > thanks
> > > > Enrico
> > > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Neng

[GitHub] [pulsar-site] urfreespace merged pull request #104: fix build script about crowdin

[GitBox]

urfreespace merged PR #104:
URL: https://github.com/apache/pulsar-site/pull/104


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-dotpulsar] RobertIndie commented on issue #105: Support - Custom authentication

[GitBox]

RobertIndie commented on issue #105:
URL: 
https://github.com/apache/pulsar-dotpulsar/issues/105#issuecomment-1149609173

   I think we may need to add reflection support here. Users only need to 
provide the required class name and auth parameters to generate the 
IAuthentication.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-site] urfreespace merged pull request #103: crowdin swith

[GitBox]

urfreespace merged PR #103:
URL: https://github.com/apache/pulsar-site/pull/103


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] PIP-175: Extend time based release process

[Haiting Jiang]

>  I was actually not thinking of changing the denomination of 2.11. On
> one hand, it could make sense for being the first Java 17 release, but
> on the other, we'd be releasing 2 LTSs super close between each other
> and we'd have to support 1 release more for the time being.
> 
> I'd like to hear more opinions here :)

It's a little confusing here, if 2.10 is LTS for being the last Java 8 release, 
will there be feature release for 2.10 LTS, and 2.10.x are both feature release 
and patch release?

Thanks,
Haiting

On 2022/06/07 23:39:23 Matteo Merli wrote:
> > > There is a high cost to maintain a lot of old releases, backport bug
> > > fixes, and security patches. In general, we actively support the last
> > > 3 minor releases while continuing to develop the next release. E.g.,
> > > 2.8, 2.9, and 2.10, while 2.11 is under development.
> >
> > Is 2.7 EOL? If so then we need to announce it explicitly.
> 
> Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be 
> included.
> The point though still remains in that there's nowhere in the website
> where a user could check until when the 2.7 release is going to be
> supported.
> 
> > > We need to ensure that we have a date set in stone to deliver the
> > > release to users.
> >
> > I would like the new plan to address the delays in cherry picking changes. 
> > These must never wait until a release is being made. We must keep these up 
> > to date. If someone marks a PR for an older release then they are 
> > volunteering to do the cherry pick within a few days. We need to be 
> > prepared for a 0-day security release.
> 
> I agree that this is a problem, though I'd prefer to keep it in a
> separate proposal, specifically targeted at the process for patch
> releases, to avoid putting too many things into a single discussion.
> 
> > > The major version bump will not carry any special meaning in terms of
> > > "big features" included in the release or breaking API changes.
> > > Instead, it would simply signal the type of the release.
> >
> > From our existing release what is LTS?
> 
> Good point, as we discussed earlier, 2.10 should be marked as LTS for
> being the last Java 8 release. I'll update the text to reflect this.
> 
> > Does this mean that you are proposing the current Master as release/3.0 or 
> > will it remain 2.11?
> 
>  I was actually not thinking of changing the denomination of 2.11. On
> one hand, it could make sense for being the first Java 17 release, but
> on the other, we'd be releasing 2 LTSs super close between each other
> and we'd have to support 1 release more for the time being.
> 
> I'd like to hear more opinions here :)
> 
> > > The support model will be:
> > >
> > > * LTS
> > >   * Released every 18 months
> > >   * Support for 24 months
> > >   * Security patches for 36 months
> > > * Feature releases
> > >   * Released every 3 months
> > >   * Support for 6 months
> > >   * Security patches for 6 months
> >
> > Are those times since the initial release? It would be helpful to have a 
> > swim lane diagram.
> 
> Yes, from the initial release (eg: 3.0.0) and yes we would have a
> clear diagram on the website.
> 
> > > This can be translated into:
> > >   * We support the last 2 LTS releases and the last 2 feature releases
> > >   * Security patches are provided for the past 3 LTS releases and 2
> > > feature releases
> >
> > Please note that in the event of a security release that PMC members will 
> > generally need to do these in secret.
> 
> No changes about that. This is only to set the user expectation for
> how long they can expect the security patches.
> 
> It doesn't change a comma on the PMC process of discussing such
> releases, nor it would prevent doing additional security releases
> outside of the "guaranteed" window.
> 
> > What is the plan for bug fix / security releases on say 3.0?
> 
> Since 3.0 would be LTS, based on the above-proposed table: 2y for bug
> fixes - 3y for security patches
>