Hi Dezhi, and Teng, FYI. Here is the thread that discusses JDK 17. On Thu, May 12, 2022 at 8:22 AM Matteo Merli <matteo.me...@gmail.com> wrote:
> -- > Matteo Merli > <matteo.me...@gmail.com> > > On Wed, May 11, 2022 at 11:10 AM Dave Fisher <w...@apache.org> wrote: > > > > > > > > > On May 11, 2022, at 6:39 AM, Matteo Merli <matteo.me...@gmail.com> > wrote: > > > > > > On Wed, May 11, 2022 at 1:10 AM Enrico Olivelli <eolive...@gmail.com> > 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. >
