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