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

2022-11-06 Thread Shwetha Acharya 
Hi Amar,

We will be branching out release 11 this week.

Regards,
Shwetha

On Mon, Nov 7, 2022 at 9:47 AM Amar Tumballi  wrote:

> 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 
> wrote:
>
>> On Mon, Oct 17, 2022 at 10:40 AM Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez 
>>> wrote:
>>>
 On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi  wrote:

> Here is my honest take on this one.
>
> On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya 
> 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/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

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

2022-11-06 Thread 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  wrote:

> On Mon, Oct 17, 2022 at 10:40 AM Yaniv Kaul  wrote:
>
>>
>>
>> On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez 
>> wrote:
>>
>>> On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi  wrote:
>>>
 Here is my honest take on this one.

 On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya 
 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/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

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

2022-10-17 Thread Xavi Hernandez 
On Mon, Oct 17, 2022 at 10:40 AM Yaniv Kaul  wrote:

>
>
> On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez 
> wrote:
>
>> On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi  wrote:
>>
>>> Here is my honest take on this one.
>>>
>>> On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya 
>>> 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/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.
>
>
>>

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

2022-10-17 Thread Yaniv Kaul 
On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez  wrote:

> On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi  wrote:
>
>> Here is my honest take on this one.
>>
>> On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya 
>> 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/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 have this for one for inode related code, which got some attention
recently:
https://github.com/gluster/glusterfs/pull/3226

I think this one is worthwhile looking at:
https://github.com/gluster/glusterfs/pull/3854

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)

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).

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.

(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-de...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

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

2022-10-16 Thread Xavi Hernandez 
On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi  wrote:

> Here is my honest take on this one.
>
> On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya 
> 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.

Xavi
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

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

2022-10-16 Thread Amar Tumballi 
Here is my honest take on this one.

On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya  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.

Regards,
Amar

> Regards,
> Shwetha
> ___
> maintainers mailing list
> maintainers@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>


-- 
--
https://kadalu.io
Container Storage made easy!
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers