Re: [Gluster-Maintainers] [for discussion] suggestions around improvements in bug triage workflow

[Shyam Ranganathan]

On 09/27/2018 11:33 AM, Atin Mukherjee wrote:
> 
> 
> On Thu, 27 Sep 2018 at 20:37, Sankarshan Mukhopadhyay
>  > wrote:
> 
> The origin of this conversation is a bit of a hall-way discussion with
> Shyam. The actual matter should be familiar to maintainers. For what
> it is worth, it was also mentioned at the recent Community meeting.
> 
> As the current workflows go, once a release is made generally
> available, a large swathe of bugs against an EOLd release are
> automatically closed citing that "the release is EOLd and if the bug
> is still reproducible on later releases, please reopen against those".
> However, there is perhaps a better way to handle this:
> 
> 
> I will play a devil’s advocate role here, but one of the question we
> need to ask ourselves additionally:
> 
> - Why are we getting into such state where so many bugs primarily the
> ones which haven’t got development’s attention get auto closed due to EOL?
> - Doesn’t this indicate we’re actually piling up our backlog with
> (probable) genuine defects and not taking enough action?
> 
> Bugzilla triage needs to be made as a habit by individuals to ensure new
> bugs get attention. Technically this will no longer be a problem.

Agree, further when the triage is done, if problem is release specific
then we can let bug be, else cloning it against master will ensure the
bug is tracked and even if we EOL bugs against a release, the bug report
survives against master till it is fixed.
 
> 
> However, for now I think this workflow sounds a right measure atleast to
> ensure we don’t close down a genuine defect.
> 
> 
> 
> [0] clone the bug into master so that it continues to be part of a
> valid bug backlog
> 
> [1] validate per release that the circumstances described by the bug
> are actually resolved and hence CLOSED CURRENTRELEASE them
> 
> I am posting here for discussion around this as well as being able to
> identify whether tooling/automation can be used to handle some of
> this.

As part of the a release EOL, such a job needs to be taken up. Till
triaging improves, cloning the bug against master and closing the
release bug would be a viable option to proceed with.

If the quantum of bugs are within a reasonable number (say 20 odd) then
we can even triage them then and take action, else tooling needs to be
in place.

I will keep a watch out when we EOL 3.12 as release-5 goes out to see
how much of an issue this is to do manually.

> 
> 
> 
> -- 
> sankarshan mukhopadhyay
> 
> ___
> maintainers mailing list
> maintainers@gluster.org 
> https://lists.gluster.org/mailman/listinfo/maintainers
> 
> -- 
> - Atin (atinm)
> 
> 
> ___
> maintainers mailing list
> maintainers@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
> 
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] [for discussion] suggestions around improvements in bug triage workflow

[Atin Mukherjee]

On Thu, 27 Sep 2018 at 20:37, Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:

> The origin of this conversation is a bit of a hall-way discussion with
> Shyam. The actual matter should be familiar to maintainers. For what
> it is worth, it was also mentioned at the recent Community meeting.
>
> As the current workflows go, once a release is made generally
> available, a large swathe of bugs against an EOLd release are
> automatically closed citing that "the release is EOLd and if the bug
> is still reproducible on later releases, please reopen against those".
> However, there is perhaps a better way to handle this:


I will play a devil’s advocate role here, but one of the question we need
to ask ourselves additionally:

- Why are we getting into such state where so many bugs primarily the ones
which haven’t got development’s attention get auto closed due to EOL?
- Doesn’t this indicate we’re actually piling up our backlog with
(probable) genuine defects and not taking enough action?

Bugzilla triage needs to be made as a habit by individuals to ensure new
bugs get attention. Technically this will no longer be a problem.

However, for now I think this workflow sounds a right measure atleast to
ensure we don’t close down a genuine defect.


>
> [0] clone the bug into master so that it continues to be part of a
> valid bug backlog
>
> [1] validate per release that the circumstances described by the bug
> are actually resolved and hence CLOSED CURRENTRELEASE them
>
> I am posting here for discussion around this as well as being able to
> identify whether tooling/automation can be used to handle some of
> this.
>
>
>
> --
> sankarshan mukhopadhyay
> 
> ___
> maintainers mailing list
> maintainers@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>
-- 
- Atin (atinm)
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers

[Gluster-Maintainers] [for discussion] suggestions around improvements in bug triage workflow

[Sankarshan Mukhopadhyay]

The origin of this conversation is a bit of a hall-way discussion with
Shyam. The actual matter should be familiar to maintainers. For what
it is worth, it was also mentioned at the recent Community meeting.

As the current workflows go, once a release is made generally
available, a large swathe of bugs against an EOLd release are
automatically closed citing that "the release is EOLd and if the bug
is still reproducible on later releases, please reopen against those".
However, there is perhaps a better way to handle this:

[0] clone the bug into master so that it continues to be part of a
valid bug backlog

[1] validate per release that the circumstances described by the bug
are actually resolved and hence CLOSED CURRENTRELEASE them

I am posting here for discussion around this as well as being able to
identify whether tooling/automation can be used to handle some of
this.



-- 
sankarshan mukhopadhyay

___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers