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

[Xavi Hernandez]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20221017/ab0d343a/attachment.html>