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

[Niels de Vos]

On Thu, Oct 12, 2017 at 10:28:01AM +0530, Nithya Balachandran wrote:
> 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.

We do not use flags at all at the moment. Flags are something that is
rather difficult to understand for non Red Hat Bugzilla experts. Also, I
can request a blocker flag for bugs, but can not approve it. We would
need to figure out who/when/how to give permissions to approve flags.

Blocker/tracker bugs are well understood in most Open Source
communities, and do not require extra permissions to request/approve. I
would vote to keep the process as simple and open as possible.

As Shyam mentioned in an other reply, there is no need for all bugs for
a release to be attched to the blocker/tracker bug. When the bugs get
closed, they get their "Fixed in version" field set, so users can easily
identify the version (or newer) they need.

There is a definite overhead in reviewing all attached bugs to the
release tracker. Moving them to a next release should not be considered
to be a light decision. Bug that are not attached to a tracker can still
be fixed in a release, and will get listed in the release notes and
announcement.

HTH,
Niels


> 
> 
> 
> > 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
> >

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel