[Gluster-devel] Locating blocker bugs for a release (and what is a blocker anyway)

[Nithya Balachandran]

On 12 October 2017 at 10:12, Raghavendra Talur <rtalur at redhat.com> wrote:

> On Wed, Oct 11, 2017 at 8:35 PM, Shyam Ranganathan <srangana at 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 at gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20171012/cf795b9e/attachment.html>