[Gluster-Maintainers] [Gluster-devel] Release 11: Revisting our proposed timeline and features

[Amar Tumballi]

Other than 2 large PRs (CDC and zlib changes) we don't have any major
pending tasks. I would like to propose we keep up with the proposed dates,
and go ahead with the branching. If we merge these PRs, we can rebase and
send it to the branch again.

Shwetha Can you please go ahead with the branching related activities?

-Amar

On Mon, Oct 17, 2022 at 3:24 PM Xavi Hernandez <jahernan at redhat.com> wrote:

> On Mon, Oct 17, 2022 at 10:40 AM Yaniv Kaul <ykaul at redhat.com> wrote:
>
>>
>>
>> On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez <jahernan at redhat.com>
>> wrote:
>>
>>> On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi <amar at kadalu.io> wrote:
>>>
>>>> Here is my honest take on this one.
>>>>
>>>> On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya <sacharya at redhat.com>
>>>> wrote:
>>>>
>>>>> It is time to evaluate the fulfillment of our committed
>>>>> features/improvements and the feasibility of the proposed deadlines as per Release
>>>>> 11 tracker <https://github.com/gluster/glusterfs/issues/3023>.
>>>>>
>>>>>
>>>>> Currently our timeline is as follows:
>>>>>
>>>>> Code Freeze: 31-Oct-2022
>>>>> RC : 30-Nov-2022
>>>>> GA : 10-JAN-2023
>>>>>
>>>>> *Please evaluate the following and reply to this thread if you want to
>>>>> convey anything important:*
>>>>>
>>>>> - Can we ensure to fulfill all the proposed requirements by the Code
>>>>> Freeze?
>>>>> - Do we need to add any more changes to accommodate any shortcomings
>>>>> or improvements?
>>>>> - Are we all good to go with the proposed timeline?
>>>>>
>>>>>
>>>> We have delayed the release already by more than 1year, and that is a
>>>> significant delay for any project. If the changes we work on is not getting
>>>> released frequently, the feedback loop for the project is delayed and hence
>>>> the further improvements. So, regardless of any pending promised things, we
>>>> should go ahead with the code-freeze and release on these dates.
>>>>
>>>> It is crucial for any projects / companies dependent on the project to
>>>> plan accordingly. There may be already few others who would have planned
>>>> their product release around these dates. Lets keep the same dates, and try
>>>> to achieve the tasks we have planned in these dates.
>>>>
>>>
>>> I agree. Pending changes will need to be added to next release. Doing it
>>> at last time is not safe for stability.
>>>
>>
>> Generally, +1.
>>
>> - Some info on my in-flight PRs:
>>
>> I have multiple independent patches for the flexible array member
>> conversion of different variables that are pending:
>> https://github.com/gluster/glusterfs/pull/3873
>> https://github.com/gluster/glusterfs/pull/3872
>> https://github.com/gluster/glusterfs/pull/3868  (this one is
>> particularly interesting, I hope it works!)
>> https://github.com/gluster/glusterfs/pull/3861
>> https://github.com/gluster/glusterfs/pull/3870 (already in review,
>> perhaps it can get it soon?)
>>
>
> I'm already looking at these and I expect they can be merged before the
> current code-freeze date.
>
>
>> I have this for one for inode related code, which got some attention
>> recently:
>> https://github.com/gluster/glusterfs/pull/3226
>>
>
> I'll try to review this one before code-freeze, but it requires much more
> care. Any help will be appreciated.
>
>
>>
>> I think this one is worthwhile looking at:
>> https://github.com/gluster/glusterfs/pull/3854
>>
>
> I'll try to take a look at this one also.
>
>
>> I wish we could get rid of old, unsupported versions:
>> https://github.com/gluster/glusterfs/pull/3544
>> (there's more to do, in different patches, but it's a start)
>>
>
> This one is mostly ok, but I think we can't release a new version without
> an explicit check for unsupported versions at least at the beginning, to
> avoid problems when users upgrade directly from 3.x to 11.x.
>
>
>> None of them is critical for release 11, though I'm unsure if I'll have
>> the ability to complete them later.
>>
>>
>> - The lack of EL9 official support (inc. testing infra.) is regrettable,
>> and I think something worth fixing *before* release 11 - adding sanity
>> on newer OS releases, which will use io_uring for example, is something we
>> should definitely consider.
>>
>> Lastly, I thought zstandard compression to the CDC xlator is interesting
>> for 11 (https://github.com/gluster/glusterfs/pull/3841) - unsure if it's
>> ready for inclusion, but overall impact for stability should be low,
>> considered this is not a fully supported xlator anyway (and then
>> https://github.com/gluster/glusterfs/pull/3835 should / could be
>> considered as well).
>>
>
> I already started the review but I'm not very familiarized with cdc and
> the compression libraries, so I'll need some more time.
>
>
>>
>> Last though:
>> If we are just time-based - sure, there's value in going forward and
>> releasing it - there are hundreds (or more) of great patches already
>> merged, I think there's value here.
>> If we wish to look at features and impactful changes to the users - I
>> suggest we review https://github.com/gluster/glusterfs/issues/3023 , we
>> look at what's missing, what's in-flight and can get in, draft the release
>> announcement and see if there's enough content.
>>
>
> At this point I don't think any of the remaining big features can be
> added, and given that release 11 has already been delayed quite a bit, I
> agree with Amar that we should provide a new version soon. I think it
> already contains very interesting changes that can improve performance and
> stability.
>
>
>> (I'm for the former, I just think the latter is a good reasonable
>> exercise to see what's in 11!)
>> Y.
>>
>>
>>> Xavi
>>> -------
>>>
>>> Community Meeting Calendar:
>>> Schedule -
>>> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
>>> Bridge: https://meet.google.com/cpu-eiue-hvk
>>>
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>>

-- 
--
https://kadalu.io
Container Storage made easy!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20221107/e6a9c4f2/attachment.html>