On 12 October 2017 at 10:12, Raghavendra Talur <rtalur@xxxxxxxxxx> wrote:
I have used it a little differently. On the day of release, I add allOn Wed, Oct 11, 2017 at 8:35 PM, Shyam Ranganathan <srangana@xxxxxxxxxx> 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.
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@xxxxxxxxxxx
> http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
