> On Sep 29, 2021, at 2:10 AM, Masakazu Kitajo <mas...@apache.org> wrote:
>
> I'm not sure if we are on the same page. We review PRs for master. The
> process itself stays the same. I'm trying to say we should refrain from
> making changes that are not going to be cherry-picked to 9.2.x branch until
> we release 9.2.0. If you find a regression on 9.2.x, you can make a PR for
> master and I'll review it, and it should be cherry-picked to 9.2.x. If you
> have a serious bugfix that can't wait for 9.2.0 then you can make a PR for
> master and I'll review it. The fix should be cherry-picked to 9.1.x and
> also 9.2.x. If you have something for 10.0, you can make a PR for master,
> but I personally postpone the review and I hope others follow. The point is
> how much resources we spend on 9.2.x and 10.0.x over the next few months.
> 90:10, 70:30 or 50:50?
Gotcha. I think that’s something for the community as a whole to decide,
whether essentially master is frozen for a few months while making a release
production ready. There’s zero chance that we could make 9.2.x production ready
in “days” or “weeks”, from previous experiences, no matter how much we all
agree to work on it. :)
Bryan, this would be a big change in our development and release process, what
do you say?
>
> If you aim for late November and know it will take time, what are you
> waiting for? Isn't it time to "Do we really need this in 9.2.x?" on
> existing PRs?
That’s exactly where we are now! Nothing goes into 9.2.x unless deemed needed.
It’s the whole point of merging it. I don’t want to call it a feature freeze,
at least not yet, but we can discuss the exact process and requirements if we
want to formalize it and the time frames more accurately.
Cheers,
— Leif
>
> Masakazu
>
>
> On Wed, Sep 29, 2021 at 2:01 PM Leif Hedstrom <zw...@apache.org> wrote:
>
>> Well, we shouldn’t merge PRs to master which are not properly reviewed. If
>> the consensus is that we stop merging on master until 9.2.x is stable, then
>> that would make sense. But then again, how do we fix things then for 9.2.x
>> or other versions if no one is reviewing master branch PRs. I’ll leave that
>> to Bryan to figure out :).
>>
>> No one tests anything on master so we have about 300 PRs now on 9.2.x that
>> needs to be tested properly. This will take time. I think a two months
>> cycle for 9.2.x as suggested in the email can work, but is likely
>> optimistic.
>>
>> — Leif
>>
>>> On Sep 28, 2021, at 22:21, Masakazu Kitajo <mas...@apache.org> wrote:
>>>
>>> I understand all changes has to be landed on master first and that's
>> fine,
>>> but active development for future releases (9.3 or 10.0) on master after
>>> branching 9.2.x increase the gap between the two and cherry-picking gets
>>> difficult day by day. "10-Dev" branch probably mitigate it, but I don't
>> see
>>> reasons to keep 9.2.x unreleased for a long time after the branching. I
>>> think we should focus on stabilizing it and release 9.2.0 soon before it
>>> gets hard like 9.1.0 release. This is why I asked what the branching
>> means
>>> and indirectly suggested calling a feature freeze.
>>>
>>> What I'm trying to do with my review suspension for some PRs is
>>> prioritizing changes for next release. Changes for 10.x don't need to be
>>> reviewed today regardless of whether those are invasive / incompatible or
>>> not. Issues that have been there on 9.1.x releases don't necessarily have
>>> to be resolved on 9.2.x. Even a bug fix can make a new bug. What we need
>> to
>>> do to stabilize 9.2.x is resolving issues that didn't exist on 9.1.x,
>> such
>>> as regressions and bugs in new features on 9.2, and I'm going to review
>>> only those PRs until we release 9.2.0.
>>>
>>> If any of you wanted to annoy RM like we did for 9.1.0 release, request
>>> reviews from someone else ;-)
>>>
>>> Masakazu
>>>
>>>> On Wed, Sep 29, 2021 at 7:31 AM Leif Hedstrom <zw...@apache.org> wrote:
>>>>
>>>>
>>>>
>>>>>> On Sep 28, 2021, at 3:37 AM, Masakazu Kitajo <mas...@apache.org>
>> wrote:
>>>>>
>>>>> Can you clarify what branching 9.2.x means (again)?
>>>>
>>>> It means, branched from master -> 9.2.x. Going forward, anything that we
>>>> want in 9.2.x must be marked with “Project 9.2.x” (remember, Milestone
>> is
>>>> still 10.0.0), and I will cherry pick those PRs which should go into
>> 9.2.x.
>>>>
>>>>> I don't have a strong opinion on the release date, but I think RM
>> should
>>>>> clearly call a feature freeze sooner rather than later and we all
>> should
>>>>> focus on stabilizing the branch because we already have many changes
>> for
>>>>> 9.2.0.
>>>>
>>>> Agreed. v9.2.x is not “feature frozen” yet, but will be. We can
>> certainly
>>>> pick a hard date for this if that’s the community concsent?
>>>>>
>>>>> I'm personally going to suspend reviewing PRs for 10.0, PRs that try to
>>>> add
>>>>> new features to 9.x, and PRs that try to resolve issues on previous
>>>>> releases (except security issues).
>>>>
>>>> Hmmm, what PRs does that leave then? ;-). Everyone should review all
>>>> 10.0.x (master) PRs, only those PRs landed on master would ever be
>>>> considered going into any 9.x release. I can understand not reviewing
>> PRs
>>>> going into “10-Dev”, those are the invasive / incompatible PRs that we
>> want
>>>> for 10.0.0, but which can not go into 9.x.
>>>>
>>>> Cheers,
>>>>
>>>> — Leif
>>>>
>>>>>
>>>>> Masakazu
>>>>>
>>>>>> On Sat, Sep 18, 2021 at 1:52 AM Leif Hedstrom <zw...@apache.org>
>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I’m going to branch v9.2.x, from current master, Monday morning, 9/20.
>>>> We
>>>>>> will continue development on v9.2.0 of course, but remember that you
>>>> will
>>>>>> need to mark PRs with “Project 9.2.x” for consideration into the
>>>> upcoming
>>>>>> branch. I’d like to aim to have a v9.2.0 release either late November
>> /
>>>>>> early December, or possibly early January 2022. Please discuss if you
>>>> have
>>>>>> a preference here.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> — Leif
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
