Hi Dezhi, and Teng,
FYI. Here is the thread that discusses JDK 17.
On Thu, May 12, 2022 at 8:22 AM Matteo Merli wrote:
> --
> Matteo Merli
>
>
> On Wed, May 11, 2022 at 11:10 AM Dave Fisher wrote:
> >
> >
> >
> > > On May 11, 2022, at 6:39 AM, Matteo Merli
> wrote:
> > >
> > > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli
> wrote:
> > >> I am sorry, I missed this discussion.
> > >> But until we cut a release we are in time to change our minds, if we
> > >> find out that we can do better.
> > >
> > > Yes, but the precise point of having a PIP process is to have
> > > discussions and formalize decisions.
> >
> > One of my criticisms of the current PIP process is that there is a 2 day
> VOTE period. This is just too short for ASF project governance. Not
> everyone is online or checking the dev list in detail in that short a
> period. There are weekends, holidays, work focus (even if Pulsar is your
> job). Many PIPs are minor, but some are of very large impact and should
> perhaps have a 7 day VOTE and/or 7 days minimum discussion time.
>
> Sure, this is a very valid point. The initial reasoning for the 2 days
> was not to disrupt too much the introduction of smaller changes, since
> we went from no-process at all to this discussion/vote PIP process.
>
> We can (should!) definitely revisit the process, now that we have some
> experience with it.
> Typically, what would be challenging is to define what is "large
> impact" (even if this proposal certainly will fit the bill) as
> everyone could have different perspectives on it, but at least we can
> set the expectations to be different for different types of changes.
>
> The current PIP-156 stayed out for discussion/vote for 1 week (which I
> agree is not a whole lot of time), although it has been discussed
> informally in the community a few times before.
>
> What I'd also like to avoid is for us to go back on the same decisions
> once they're taken, unless there are new elements that were not
> considered before.
>
> > 1. We should likely declare that 2.10 releases are LTS to allow
> stability for users that must remain on Java 8.
>
> This sounds like a good point.
>
>
> > 2. We’ll need to provide clear guidance to developers on code changes
> that will be cherry picked to 2.10 and earlier versions.
>
> Sure, this is easy. We need to update the contributor/committer
> guidelines and the CI jobs will ensure that we don't slip anything
> inadvertently.
>
