Re: [Gluster-devel] 3.10 bugs
> For bugs reported by users that do not test builds from the master > branch, we ideally follow these steps [0]: Please note that this is gluster-devel, not gluster-users. Everyone on -devel should be aware of the relationship between release branches and master. > - read the description of the bug against 3.10 > - if this is a bug that is (most likely) still present in the master >branch, clone it, and have the 3.10 depend on the new mainline bug > - developers for the component get their notifications (through [1]) > - patch for the master branch get posted, reviewed merged > - developer checks if the patch needs a backport and acts upon it > > All regular contributors should be aware of this process and do the > triaging themselves when they report a new bug. The weekly bug triage > meetings on Tuesdays should only need to handle the bugs that have not > been triaged by developers responsible for the components. Waiting for the maintainer is simply waiting too long. For bugs that need to be fixed quickly, which is most of them near a release, the burden ends up falling on the developer assigned to fix the bug. It's not a big thing in itself, but in addition to all the other hoops we have to jump through I don't think it's a good idea to add one more before the patch can even be submitted to master. Maybe people who only work on one patch a month don't notice. People who sometimes submit several a day surely do. Let's remove bottlenecks instead of making them worse. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 3.10 bugs
On Fri, Feb 17, 2017 at 09:54:49AM -0500, Jeff Darcy wrote: > Please don't file bugs directly against 3.10 if they're also present > in master. Since the fix has to go into master first anyway, the bug > should be filed against that. Subsequently, the developer is > responsible for cloning both the bug and the patch for 3.10 if a > backport is needed. For bugs reported by users that do not test builds from the master branch, we ideally follow these steps [0]: - read the description of the bug against 3.10 - if this is a bug that is (most likely) still present in the master branch, clone it, and have the 3.10 depend on the new mainline bug - developers for the component get their notifications (through [1]) - patch for the master branch get posted, reviewed merged - developer checks if the patch needs a backport and acts upon it All regular contributors should be aware of this process and do the triaging themselves when they report a new bug. The weekly bug triage meetings on Tuesdays should only need to handle the bugs that have not been triaged by developers responsible for the components. Thanks, Niels [0] http://gluster.readthedocs.io/en/latest/Contributors-Guide/Bug-Triage/ [1] https://github.com/gluster/glusterdocs/blob/master/Developer-guide/Bugzilla%20Notifications.md signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
