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

[Atin Mukherjee]

On Thu, 27 Sep 2018 at 20:37, Sankarshan Mukhopadhyay <
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.

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
> <https://about.me/sankarshan.mukhopadhyay>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>
-- 
- Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180927/04cac9c8/attachment.html>