<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Sep 2018 at 20:37, Sankarshan Mukhopadhyay <<a href="mailto:sankarshan.mukhopadhyay@gmail.com">sankarshan.mukhopadhyay@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The origin of this conversation is a bit of a hall-way discussion with<br>
Shyam. The actual matter should be familiar to maintainers. For what<br>
it is worth, it was also mentioned at the recent Community meeting.<br>
<br>
As the current workflows go, once a release is made generally<br>
available, a large swathe of bugs against an EOLd release are<br>
automatically closed citing that "the release is EOLd and if the bug<br>
is still reproducible on later releases, please reopen against those".<br>
However, there is perhaps a better way to handle this:</blockquote><div dir="auto"><br></div><div dir="auto">I will play a devil’s advocate role here, but one of the question we need to ask ourselves additionally:</div><div dir="auto"><br></div><div dir="auto">- 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?</div><div dir="auto">- Doesn’t this indicate we’re actually piling up our backlog with (probable) genuine defects and not taking enough action?</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">However, for now I think this workflow sounds a right measure atleast to ensure we don’t close down a genuine defect.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
[0] clone the bug into master so that it continues to be part of a<br>
valid bug backlog<br>
<br>
[1] validate per release that the circumstances described by the bug<br>
are actually resolved and hence CLOSED CURRENTRELEASE them<br>
<br>
I am posting here for discussion around this as well as being able to<br>
identify whether tooling/automation can be used to handle some of<br>
this.<br>
<br>
<br>
<br>
-- <br>
sankarshan mukhopadhyay<br>
<<a href="https://about.me/sankarshan.mukhopadhyay" rel="noreferrer" target="_blank">https://about.me/sankarshan.mukhopadhyay</a>><br>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Atin (atinm)</div>