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

[Shyam Ranganathan]

On 10/12/2017 12:58 AM, Nithya Balachandran wrote:
>      > - 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.
> 

So here are 2 things a contributor needs to do if all bugs are marked 
against the blocker.

a) Backport it, no way to avoid this and the additional work of 
filing/cloning a bug against the release for which the backport is aimed at.

b) Add it to the tracker

(b) is not essential, it is additional work for the contributor. Further 
the bug may or may not make it to the release (as reflected above), and 
adds work for the release maintainer to cleanup the tracker and add 
those that are missed to the next release tracker.

For a release maintainer (or anyone with a cloned repository), the 
ability to find bugs that are fixed in a release is relatively simple. 
It is as easy as executing this (for example),
git log --format=email v3.12.1..v3.12.2 | grep -i ^bug: | awk ‘{print 
$2}’ | sort -u

For users this list is presented in the release notes, which is part of 
the documentation, release announcement, and in github as well. Further, 
post a release bugs that were fixed as a part of the release are closed 
with a comment in bugzilla stating which release it made it to, and also 
the release announcement mail.

The above user perspective is added, as there maybe a justification that 
a user could look at the tracker and figure out is a bug is fixed in the 
said release, but this again is not required, if the bug of interest is 
known then looking at that bug in bugzilla provides the information, if 
the query is more along what all are fixed, the release notes inform 
regarding the same.

As a result, marking all bugs against the tracker, is more work for a 
contributor as well as the release maintainer. So why would we want to 
do this?

Shyam