Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Atin Mukherjee]

-Atin
Sent from one plus one
On 10-Jun-2016 6:09 PM, "Atin Mukherjee"  wrote:
>
>
>
> On 06/06/2016 10:00 AM, Vijay Bellur wrote:
> > On Fri, Jun 3, 2016 at 10:36 AM, Vijay Bellur 
wrote:
> >> On Fri, Jun 3, 2016 at 10:16 AM, Niels de Vos 
wrote:
> >>> On Thu, Jun 02, 2016 at 10:55:58PM -0400, Vijay Bellur wrote:
>  On Sun, May 29, 2016 at 9:37 PM, Vijay Bellur 
wrote:
> > Since we do not have any objections to this proposal, let us do the
> > following for 3.7.12:
> >
> > 1. Treat June 1st as the cut-off for patch acceptance in
release-3.7.
> > 2. I will tag 3.7.12rc1 on June 2nd.
> 
> 
>  Gentle reminder - I will be tagging 3.7.12rc1 in about 12 hours from
>  now. Please merge patches needed for 3.7.12 by then. Post that,
>  patches would be pushed out to 3.7.13.
> >>>
> >>> I thought we didnt do the rc releases for the stable versions anymore?
> >>> What is the reason for this change?
> >>>
> >>
> >> This is for the convenience of maintainers to submit their feedback on
> >> the release content. A tag is more convenient than a commit ID to
> >> provide feedback and log bugs if necessary. Hence the change.
> >>
> >
> > I have tagged v3.7.12rc1.
> >
> > Maintainers - please use this tag to verify contents for your
> > components and provide your feedback this week.
> GlusterD sanity tests are executed. I've focused on cluster
> expansion/shrink, volume management commands like create. start, stop,
> delete along with expansion/shrink of a volume. volume set/get features
> are also tested. Little bit of basic testing is done for tiering, quota.
> Nothing abnormal found till now. So its a green from GlusterD team.

Along with that, I've also focused on testing the recent bug fixes done in
the glusterd code space.

>
> >
> > Thanks!
> > Vijay
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> >
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Vijay Bellur]

On Fri, Jun 3, 2016 at 10:36 AM, Vijay Bellur  wrote:
> On Fri, Jun 3, 2016 at 10:16 AM, Niels de Vos  wrote:
>> On Thu, Jun 02, 2016 at 10:55:58PM -0400, Vijay Bellur wrote:
>>> On Sun, May 29, 2016 at 9:37 PM, Vijay Bellur  wrote:
>>> > Since we do not have any objections to this proposal, let us do the
>>> > following for 3.7.12:
>>> >
>>> > 1. Treat June 1st as the cut-off for patch acceptance in release-3.7.
>>> > 2. I will tag 3.7.12rc1 on June 2nd.
>>>
>>>
>>> Gentle reminder - I will be tagging 3.7.12rc1 in about 12 hours from
>>> now. Please merge patches needed for 3.7.12 by then. Post that,
>>> patches would be pushed out to 3.7.13.
>>
>> I thought we didnt do the rc releases for the stable versions anymore?
>> What is the reason for this change?
>>
>
> This is for the convenience of maintainers to submit their feedback on
> the release content. A tag is more convenient than a commit ID to
> provide feedback and log bugs if necessary. Hence the change.
>

I have tagged v3.7.12rc1.

Maintainers - please use this tag to verify contents for your
components and provide your feedback this week.

Thanks!
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Niels de Vos]

On Thu, Jun 02, 2016 at 10:55:58PM -0400, Vijay Bellur wrote:
> On Sun, May 29, 2016 at 9:37 PM, Vijay Bellur  wrote:
> > Since we do not have any objections to this proposal, let us do the
> > following for 3.7.12:
> >
> > 1. Treat June 1st as the cut-off for patch acceptance in release-3.7.
> > 2. I will tag 3.7.12rc1 on June 2nd.
> 
> 
> Gentle reminder - I will be tagging 3.7.12rc1 in about 12 hours from
> now. Please merge patches needed for 3.7.12 by then. Post that,
> patches would be pushed out to 3.7.13.

I thought we didnt do the rc releases for the stable versions anymore?
What is the reason for this change?

Thanks,
Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Vijay Bellur]

On Sun, May 29, 2016 at 10:19 PM, Sankarshan Mukhopadhyay
 wrote:
> On Mon, May 30, 2016 at 7:07 AM, Vijay Bellur  wrote:
>> Since we do not have any objections to this proposal, let us do the
>> following for 3.7.12:
>>
>> 1. Treat June 1st as the cut-off for patch acceptance in release-3.7.
>> 2. I will tag 3.7.12rc1 on June 2nd.
>> 3. All maintainers to ack content and stability of components by June 9th.
>> 4. Release 3.7.12 around June 9th after we have all acks in place.
>
> Would 3 days be sufficient to get the content for the website and a
> bit of PR written up?
>

Should be ample time for a minor release.

Regards,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Sankarshan Mukhopadhyay]

On Mon, May 30, 2016 at 7:07 AM, Vijay Bellur  wrote:
> Since we do not have any objections to this proposal, let us do the
> following for 3.7.12:
>
> 1. Treat June 1st as the cut-off for patch acceptance in release-3.7.
> 2. I will tag 3.7.12rc1 on June 2nd.
> 3. All maintainers to ack content and stability of components by June 9th.
> 4. Release 3.7.12 around June 9th after we have all acks in place.

Would 3 days be sufficient to get the content for the website and a
bit of PR written up?

-- 
sankarshan mukhopadhyay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Kaushal M]

On Fri, May 13, 2016 at 9:37 AM, Amye Scavarda  wrote:
> So, as I review this, we have a few different guidelines for maintainers and
> release processes.
> We have ReadtheDocs [1], the old Community site [2] and the RTD
> documentation for releases [3]  -- while 1 and 2 look nearly identical, 2
> will eventually disappear so that we're not maintaining two active copies.
> Should we be consolidating these new guidelines into a new page in RTD?
>

These are essentially 2 different topics, and should remain so.

Guildelines for Maintainers should be describing a maintainers
responsibilities to the project and the community.
GlusterFS Release process describes how a release manager/maintainer
would perform a GlusterFS release.

But we're hoping to improve the release process to make component
maintainers a part of it.
If we get more agreement, helping out with the release will become a
maintainer responsibility and will be added to the maintainer
guidelines.
How the maintainers would help out with the process will be added to
the release process.


> - amye
>
> [1]
> https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/
> [2]
> http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers
> [3]
> https://gluster.readthedocs.io/en/latest/Contributors-Guide/GlusterFS-Release-process/
>
> On Fri, May 13, 2016 at 3:13 AM, FNU Raghavendra Manjunath
>  wrote:
>>
>> +1.
>>
>>
>>
>> On Tue, May 10, 2016 at 2:58 AM, Kaushal M  wrote:
>>>
>>> On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur 
>>> wrote:
>>> > Hi All,
>>> >
>>> > We are blocked on 3.7.12 owing to this proposal. Appreciate any
>>> > feedback on this!
>>> >
>>> > Thanks,
>>> > Vijay
>>> >
>>> > On Thu, Apr 28, 2016 at 11:58 PM, Vijay Bellur 
>>> > wrote:
>>> >> Hi All,
>>> >>
>>> >> We have encountered a spate of regressions in recent 3.7.x releases.
>>> >> The
>>> >> 3.7.x maintainers are facing additional burdens to ensure functional,
>>> >> performance and upgrade correctness. I feel component maintainers
>>> >> should own
>>> >> these aspects of stability as we own the components and understand our
>>> >> components better than anybody else. In order to have more active
>>> >> participation from maintainers for every release going forward, I
>>> >> propose
>>> >> this process:
>>> >>
>>> >> 1. All component maintainers will need to provide an explicit ack
>>> >> about the
>>> >> content and quality of their respective components before a release is
>>> >> tagged.
>>> >>
>>> >> 2. A release will not be tagged if any component is not acked by a
>>> >> maintainer.
>>> >>
>>> >> 3. Release managers will co-ordinate getting acks from maintainers and
>>> >> perform necessary housekeeping (closing bugs etc.).
>>> >>
>>> >> This is not entirely new and a part of this process has been outlined
>>> >> in the
>>> >> Guidelines for Maintainers [1] document. I am inclined to enforce this
>>> >> process with more vigor to ensure that we do better on quality &
>>> >> stability.
>>> >>
>>> >> Thoughts, questions and feedback about the process are very welcome!
>>> >>
>>>
>>> +1 from me. Spreading out the verification duties will help us do
>>> better releases.
>>>
>>> >> Thanks,
>>> >> Vijay
>>> >>
>>> >> [1]
>>> >>
>>> >> http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers
>>> >>
>>> >>
>>> > ___
>>> > maintainers mailing list
>>> > maintain...@gluster.org
>>> > http://www.gluster.org/mailman/listinfo/maintainers
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>> ___
>> maintainers mailing list
>> maintain...@gluster.org
>> http://www.gluster.org/mailman/listinfo/maintainers
>>
>
>
>
> --
> Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Amye Scavarda]

So, as I review this, we have a few different guidelines for maintainers
and release processes.
We have ReadtheDocs [1], the old Community site [2] and the RTD
documentation for releases [3]  -- while 1 and 2 look nearly identical, 2
will eventually disappear so that we're not maintaining two active copies.
Should we be consolidating these new guidelines into a new page in RTD?

- amye

[1]
https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/

[2]
http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers

[3]
https://gluster.readthedocs.io/en/latest/Contributors-Guide/GlusterFS-Release-process/


On Fri, May 13, 2016 at 3:13 AM, FNU Raghavendra Manjunath <
rab...@redhat.com> wrote:

> +1.
>
>
>
> On Tue, May 10, 2016 at 2:58 AM, Kaushal M  wrote:
>
>> On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur 
>> wrote:
>> > Hi All,
>> >
>> > We are blocked on 3.7.12 owing to this proposal. Appreciate any
>> > feedback on this!
>> >
>> > Thanks,
>> > Vijay
>> >
>> > On Thu, Apr 28, 2016 at 11:58 PM, Vijay Bellur 
>> wrote:
>> >> Hi All,
>> >>
>> >> We have encountered a spate of regressions in recent 3.7.x releases.
>> The
>> >> 3.7.x maintainers are facing additional burdens to ensure functional,
>> >> performance and upgrade correctness. I feel component maintainers
>> should own
>> >> these aspects of stability as we own the components and understand our
>> >> components better than anybody else. In order to have more active
>> >> participation from maintainers for every release going forward, I
>> propose
>> >> this process:
>> >>
>> >> 1. All component maintainers will need to provide an explicit ack
>> about the
>> >> content and quality of their respective components before a release is
>> >> tagged.
>> >>
>> >> 2. A release will not be tagged if any component is not acked by a
>> >> maintainer.
>> >>
>> >> 3. Release managers will co-ordinate getting acks from maintainers and
>> >> perform necessary housekeeping (closing bugs etc.).
>> >>
>> >> This is not entirely new and a part of this process has been outlined
>> in the
>> >> Guidelines for Maintainers [1] document. I am inclined to enforce this
>> >> process with more vigor to ensure that we do better on quality &
>> stability.
>> >>
>> >> Thoughts, questions and feedback about the process are very welcome!
>> >>
>>
>> +1 from me. Spreading out the verification duties will help us do
>> better releases.
>>
>> >> Thanks,
>> >> Vijay
>> >>
>> >> [1]
>> >>
>> http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers
>> >>
>> >>
>> > ___
>> > maintainers mailing list
>> > maintain...@gluster.org
>> > http://www.gluster.org/mailman/listinfo/maintainers
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
>


-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[FNU Raghavendra Manjunath]

+1.



On Tue, May 10, 2016 at 2:58 AM, Kaushal M  wrote:

> On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur  wrote:
> > Hi All,
> >
> > We are blocked on 3.7.12 owing to this proposal. Appreciate any
> > feedback on this!
> >
> > Thanks,
> > Vijay
> >
> > On Thu, Apr 28, 2016 at 11:58 PM, Vijay Bellur 
> wrote:
> >> Hi All,
> >>
> >> We have encountered a spate of regressions in recent 3.7.x releases. The
> >> 3.7.x maintainers are facing additional burdens to ensure functional,
> >> performance and upgrade correctness. I feel component maintainers
> should own
> >> these aspects of stability as we own the components and understand our
> >> components better than anybody else. In order to have more active
> >> participation from maintainers for every release going forward, I
> propose
> >> this process:
> >>
> >> 1. All component maintainers will need to provide an explicit ack about
> the
> >> content and quality of their respective components before a release is
> >> tagged.
> >>
> >> 2. A release will not be tagged if any component is not acked by a
> >> maintainer.
> >>
> >> 3. Release managers will co-ordinate getting acks from maintainers and
> >> perform necessary housekeeping (closing bugs etc.).
> >>
> >> This is not entirely new and a part of this process has been outlined
> in the
> >> Guidelines for Maintainers [1] document. I am inclined to enforce this
> >> process with more vigor to ensure that we do better on quality &
> stability.
> >>
> >> Thoughts, questions and feedback about the process are very welcome!
> >>
>
> +1 from me. Spreading out the verification duties will help us do
> better releases.
>
> >> Thanks,
> >> Vijay
> >>
> >> [1]
> >>
> http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers
> >>
> >>
> > ___
> > maintainers mailing list
> > maintain...@gluster.org
> > http://www.gluster.org/mailman/listinfo/maintainers
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

[Kaushal M]

On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur  wrote:
> Hi All,
>
> We are blocked on 3.7.12 owing to this proposal. Appreciate any
> feedback on this!
>
> Thanks,
> Vijay
>
> On Thu, Apr 28, 2016 at 11:58 PM, Vijay Bellur  wrote:
>> Hi All,
>>
>> We have encountered a spate of regressions in recent 3.7.x releases. The
>> 3.7.x maintainers are facing additional burdens to ensure functional,
>> performance and upgrade correctness. I feel component maintainers should own
>> these aspects of stability as we own the components and understand our
>> components better than anybody else. In order to have more active
>> participation from maintainers for every release going forward, I propose
>> this process:
>>
>> 1. All component maintainers will need to provide an explicit ack about the
>> content and quality of their respective components before a release is
>> tagged.
>>
>> 2. A release will not be tagged if any component is not acked by a
>> maintainer.
>>
>> 3. Release managers will co-ordinate getting acks from maintainers and
>> perform necessary housekeeping (closing bugs etc.).
>>
>> This is not entirely new and a part of this process has been outlined in the
>> Guidelines for Maintainers [1] document. I am inclined to enforce this
>> process with more vigor to ensure that we do better on quality & stability.
>>
>> Thoughts, questions and feedback about the process are very welcome!
>>

+1 from me. Spreading out the verification duties will help us do
better releases.

>> Thanks,
>> Vijay
>>
>> [1]
>> http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers
>>
>>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel