[Gluster-Maintainers] [for discussion] suggestions around improvements in bug triage workflow
amukherj at redhat.com
Thu Sep 27 15:33:22 UTC 2018
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.
>  clone the bug into master so that it continues to be part of a
> valid bug backlog
>  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
> sankarshan mukhopadhyay
> maintainers mailing list
> maintainers at gluster.org
- Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the maintainers