[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
> <sankarshan.mukhopadhyay at gmail.com
> <mailto:sankarshan.mukhopadhyay at 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.

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
>     <https://about.me/sankarshan.mukhopadhyay>
>     _______________________________________________
>     maintainers mailing list
>     maintainers at gluster.org <mailto:maintainers at gluster.org>
>     https://lists.gluster.org/mailman/listinfo/maintainers
> 
> -- 
> - Atin (atinm)
> 
> 
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>