[Gluster-Maintainers] Bug state change proposal based on the conversation on bz 1630368

[Kaleb S. KEITHLEY]

On 11/6/18 8:45 AM, Shyam Ranganathan wrote:
> On 11/05/2018 07:00 PM, Atin Mukherjee wrote:
>> Bit late to this, but I’m in favour of the proposal.
>>
>> The script change should only consider transitioning the bug status from
>> POST to CLOSED NEXTRELEASE on master branch only. What’d be also ideal
>> is to update the fixed in version in which this patch will land.
> 
> 2 things, based on my response to this thread,
> 
> - Script will change this bug state for all branches, not just master. I
> do not see a reason to keep master special.

But master is special. Or different anyway. At least the way we're using
it it is.


> 
> - When moving the state to NEXTRELEASE I would not want to put in a
> fixed in version yet, as that may change/morph, instead it would be
> added (as it is now) when the release is made and the bug changed to
> CURRENTRELEASE.
> 
> In all, the only change is the already existing script moving a bug from
> POST to CLOSED-NEXTRELEASE instead of MODIFIED.
> 
>>
>> On Mon, 5 Nov 2018 at 21:39, Yaniv Kaul <ykaul at redhat.com
>> <mailto:ykaul at redhat.com>> wrote:
>>
>>
>>
>>     On Mon, Nov 5, 2018 at 5:05 PM Sankarshan Mukhopadhyay
>>     <sankarshan.mukhopadhyay at gmail.com
>>     <mailto:sankarshan.mukhopadhyay at gmail.com>> wrote:
>>
>>         On Mon, Nov 5, 2018 at 8:14 PM Yaniv Kaul <ykaul at redhat.com
>>         <mailto:ykaul at redhat.com>> wrote:
>>         > On Mon, Nov 5, 2018 at 4:28 PM Niels de Vos <ndevos at redhat.com
>>         <mailto:ndevos at redhat.com>> wrote:
>>         >>
>>         >> On Mon, Nov 05, 2018 at 05:31:26PM +0530, Pranith Kumar
>>         Karampuri wrote:
>>         >> > hi,
>>         >> >     When we create a bz on master and clone it to the next
>>         release(In my
>>         >> > case it was release-5.0), after that release happens can we
>>         close the bz on
>>         >> > master with CLOSED NEXTRELEASE?
>>         >
>>         >
>>         > Since no one is going to verify it (right now, but I'm hopeful
>>         this will change in the future!), no point in keeping it open.
>>         > You could keep it open and move it along the process, and then
>>         close it properly when you release the next release.
>>         > It's kinda pointless if no one's going to do anything with it
>>         between MODIFIED to CLOSED.
>>         > I mean - assuming you move it to ON_QA - who's going to do the
>>         verification?
>>         >
>>         > In oVirt, QE actually verifies upstream bugs, so there is
>>         value. They are also all appear in the release notes, with their
>>         status and so on.
>>
>>         The Glusto framework is intended to accomplish this end, is it not?
>>
>>
>>     If the developer / QE engineer developed a test case for that BZ -
>>     that would be amazing!
>>     Y.
>>     _______________________________________________
>>     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
>>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>