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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
