[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