Re: [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  wrote:
> 
> > On Wed, Oct 11, 2017 at 8:35 PM, Shyam Ranganathan 
> > 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-
> > >
> > > Replacing  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@gluster.org
> > > http://lists.gluster.org/mailman/listinfo/gluster-devel
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
> >

> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Raghavendra Talur]

On Thu, Oct 12, 2017 at 6:09 PM, Shyam Ranganathan  wrote:
> 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?

Yes, this is mainly a matter of preference. I don't have any objection
to using it as a blocker bug and adding only blockers to it.

Thanks,
Raghavendra Talur

>
> Shyam
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [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

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Nithya Balachandran]

On 12 October 2017 at 10:12, Raghavendra Talur  wrote:

> On Wed, Oct 11, 2017 at 8:35 PM, Shyam Ranganathan 
> 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-
> >
> > Replacing  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.



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

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

[Raghavendra Talur]

On Wed, Oct 11, 2017 at 8:35 PM, Shyam Ranganathan  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-
>
> Replacing  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.

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