[Gluster-devel] Locating blocker bugs for a release (and what is a blocker anyway)
srangana at redhat.com
Wed Oct 11 15:05:40 UTC 2017
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:
Replacing <VERSION> with the version for which you are attempting to
find the blocker bug for.
- 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.
- 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?
More information about the Gluster-devel