On 12 October 2017 at 10:12, Raghavendra Talur <rta...@redhat.com> wrote:
> On Wed, Oct 11, 2017 at 8:35 PM, Shyam Ranganathan <srang...@redhat.com> > wrote: > > Hi, > > > > Recently I was in some conversations that mentioned having to hunt for > the > > mail that announced the blocker bug for a release, when there is a need > to > > mark a bug as a blocker for that release. > > > > This need not be done as here is the shortcut (if you did not know) on > how > > to find the blocker, > > > > Use this URL: > > https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-<VERSION> > > > > Replacing <VERSION> with the version for which you are attempting to find > > the blocker bug for. > > > > Example: > > - https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.10.6 > > - https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.10.7 > > - https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.12.2 > > > > Some FAQs: > > > > - When is the blocker bug created? > > > > Blocker bugs are created post branching a release, so if you went around > > hunting for the 3.13.0 blocker today, it does not exist. > > > > Blocker bugs for minor releases are created post closing the prior minor > > release, and migrating any blockers that did not make it in the prior > > release to the next minor release blocker (this is only(?) possible as a > bug > > maybe marked as blocking a release post tagging the release and before > > actually announcing the release). > > > > - When to mark the blocker bug as dependent on another bug: > > > > Blockers are meant to track *just* blockers for a major or minor release, > > not all bugs that are a part of the release. Hence when a bug is > actually a > > blocker for the release, only then should the tracker be made dependent > on > > that. > > I have used it a little differently. On the day of release, I add all > the bugs that are fixed in a release in "depends on" list of the > blocker bug. Essentially, I used it as a tracker bug than a blocker > bug. > > Wouldn't it be easier that every bug that one wants to get fixed in > next minor release is added to the tracker bug and is removed and > moved to next release if it did not make it? It would be less work for > maintainer. > > +1 . We could use the blocker flag to tag actual blockers. > Talur > > > > > > - What is a blocker anyway? > > > > Blockers can be broadly classified as, regression of functionality due to > > code introduced in prior minor releases for the current version, bugs > > identified causing corruptions, bugs identified causing crashes > > > > If you believe a bug is a blocker, but still does not meet the criteria > > above, err on the safe option and call it a blocker, whose merit can > then be > > discussed on the lists and appropriate action for the release taken. > > > > - Other questions or comments? > > > > HTH, > > Shyam > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://lists.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel