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

Shyam Ranganathan srangana at redhat.com
Tue Nov 6 17:17:21 UTC 2018


On 11/06/2018 11:44 AM, Atin Mukherjee wrote:
> 
> 
> On Tue, 6 Nov 2018 at 19:57, Shyam Ranganathan <srangana at redhat.com
> <mailto:srangana at redhat.com>> wrote:
> 
>     On 11/06/2018 09:20 AM, Atin Mukherjee wrote:
>     >
>     >
>     > On Tue, Nov 6, 2018 at 7:16 PM Shyam Ranganathan
>     <srangana at redhat.com <mailto:srangana at redhat.com>
>     > <mailto:srangana at redhat.com <mailto:srangana at redhat.com>>> 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.
>     >
>     >     - 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.
>     >
>     >
>     > I can buy in the point of having the other branches also follow
>     the same
>     > rule of bug status moving to NEXTRELEASE from POST (considering we're
>     > fine to run a script during the release of mass moving them to
>     > CURRENTRELEASE) but not having the fixed in version in the bugs which
>     > are with mainline branch may raise a question/concern on what exact
>     > version this bug is being addressed at? Or is it that the post release
>     > bug movement script also considers all the bugs fixed in the master
>     > branch as well?
> 
>     Here is the way I see it,
>     - If you find a bug on master and want to know if it is
>     present/applicable for a release, you chase it's clone against the
>     release
>     - The state of the cloned bug against the release, tells you if is is
>     CURRENTRELEASE/NEXTRELEASE/or what not.
> 
>     So referring to the bug on master, to determine state on which
>     release(s) it is fixed in is not the way to find fixed state.
> 
> 
> Question : With this workflow what happens when a bug is just filed &
> fixed only in master and comes as a fix to the next release as part of
> branch out? So how would an user understand what release version is the
> fix in if we don’t have a fixed in version?

I think the workflow is explained in my other longer mail, but for this
question, the bug is moved from NEXTRELEASE->CURRENTRELEASE and the
fixed in milestone is set. This happens even today, with bugs fixed in
master that stay at MODIFIED and get CLOSED-CURRENTRELEASE with the
fixed in milestone set to the release.

> 
> 
> 
>     As a result,
>     - A bug on master with NEXTRELEASE means next major release of master.
> 
>     - A Bug on a release branch with NEXTRELEASE means, next major/minor
>     release of the branch.
> 
>     >
>     >
>     >     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>
>     >     <mailto:ykaul at redhat.com <mailto:ykaul at redhat.com>>
>     >     > <mailto:ykaul at redhat.com <mailto:ykaul at redhat.com>
>     <mailto: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>
>     >     <mailto:sankarshan.mukhopadhyay at gmail.com
>     <mailto:sankarshan.mukhopadhyay at gmail.com>>
>     >     >     <mailto:sankarshan.mukhopadhyay at gmail.com
>     <mailto:sankarshan.mukhopadhyay at gmail.com>
>     >     <mailto: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>
>     <mailto:ykaul at redhat.com <mailto:ykaul at redhat.com>>
>     >     >         <mailto:ykaul at redhat.com <mailto:ykaul at redhat.com>
>     <mailto: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>
>     <mailto:ndevos at redhat.com <mailto:ndevos at redhat.com>>
>     >     >         <mailto:ndevos at redhat.com <mailto:ndevos at redhat.com>
>     <mailto: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>
>     <mailto:maintainers at gluster.org <mailto:maintainers at gluster.org>>
>     >     <mailto:maintainers at gluster.org
>     <mailto:maintainers at gluster.org> <mailto: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 <mailto:maintainers at gluster.org>
>     <mailto:maintainers at gluster.org <mailto:maintainers at gluster.org>>
>     >     > https://lists.gluster.org/mailman/listinfo/maintainers
>     >     >
>     >
> 
> -- 
> - Atin (atinm)


More information about the maintainers mailing list