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@xxxxxxxxxx> wrote:
On Mon, Oct 17, 2022 at 10:40 AM Yaniv Kaul <ykaul@xxxxxxxxxx> wrote:On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez <jahernan@xxxxxxxxxx> wrote:On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi <amar@xxxxxxxxx> wrote:Here is my honest take on this one.On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya <sacharya@xxxxxxxxxx> 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.
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/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'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:I'll try to review this one before code-freeze, but it requires much more care. Any help will be appreciated.I'll try to take a look at this one also.I wish we could get rid of old, unsupported versions:(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@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
------- 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@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
