On Fri, May 13, 2016 at 9:37 AM, Amye Scavarda <amye@xxxxxxxxxx> 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 > <rabhat@xxxxxxxxxx> wrote: >> >> +1. >> >> >> >> On Tue, May 10, 2016 at 2:58 AM, Kaushal M <kshlmster@xxxxxxxxx> wrote: >>> >>> On Tue, May 10, 2016 at 12:01 AM, Vijay Bellur <vbellur@xxxxxxxxxx> >>> 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 <vbellur@xxxxxxxxxx> >>> > 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 >>> > maintainers@xxxxxxxxxxx >>> > http://www.gluster.org/mailman/listinfo/maintainers >>> _______________________________________________ >>> Gluster-devel mailing list >>> Gluster-devel@xxxxxxxxxxx >>> http://www.gluster.org/mailman/listinfo/gluster-devel >> >> >> >> _______________________________________________ >> maintainers mailing list >> maintainers@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/maintainers >> > > > > -- > Amye Scavarda | amye@xxxxxxxxxx | Gluster Community Lead _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel