[Gluster-devel] [Gluster-Maintainers] Release 11: Revisting our proposed timeline and features
ykaul at redhat.com
Mon Oct 17 08:40:03 UTC 2022
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>
>>> 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
>>> - Do we need to add any more changes to accommodate any shortcomings or
>>> - 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.
- 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/3868 (this one is particularly
interesting, I hope it works!)
https://github.com/gluster/glusterfs/pull/3870 (already in review, perhaps
it can get it soon?)
I have this for one for inode related code, which got some attention
I think this one is worthwhile looking at:
I wish we could get rid of old, unsupported versions:
(there's more to do, in different patches, but it's a start)
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
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.
(I'm for the former, I just think the latter is a good reasonable
exercise to see what's in 11!)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel