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 <kshlms...@gmail.com> wrote: > >> On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur <vbel...@redhat.com> >> 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 <vbel...@redhat.com> >> 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