Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of phoenix.wanglf@gmail.com
 designates 209.85.160.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <130B2C51DFC544E79C8FB185F808CF31@googlmail.com>
References: 
 <CABfS=dyGuK_Vc=mhuqVLCSFfTUtwcOhd+vrQUs-jWJ1xjkCtrg@mail.gmail.com>
	<CAJ+c7QzuroMuZfOnjwpaEU=rRG6HRxquX8_Rj=h-sgL6a6ny9w@mail.gmail.com>
	<130B2C51DFC544E79C8FB185F808CF31@googlmail.com>
Date: Thu, 5 Jul 2012 15:22:51 +0800
Message-ID: 
 <CABfS=dzfZ1CQUxBsuNJehXTnozCj6vvhcj+Coij78e27EXSHxg@mail.gmail.com>
Subject: Re: [QA]When tester can close release blocker defect
From: Li Feng Wang <phoenix.wanglf@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f642e98f36c6904c41003b5

--e89a8f642e98f36c6904c41003b5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have an idea, hope to be helpful.

maybe add items in Bugzilla can improve this workflow.

When developer change defect status to "Resolved Fixed", there need one
item "trunk version" must add.
if this defect is a release blocker, there may need another item "branch
version" must add.
or other solution like this way.

possible problem about this way:
1)Let developer feel to be forced to do something
2)May not cover some workflows.
2012/7/5 J=FCrgen Schmidt <jogischmidt@googlemail.com>

> Am Donnerstag, 5. Juli 2012 um 07:16 schrieb Ji Yan:
> > Technically, I think the release blocker defects should also be
> integrated
> > to trunk stream except for those branch stream special issue, such as
> > 119978. So as QA we should ensure the defect is fixed in both branch an=
d
> > trunk stream.
> >
> >
>
> exactly and we had already some discussion how to manage the workflow.
> It seems that the majority prefer fixing an issue on trunk first and merg=
e
> it in the branch on demand if it is a blocker issue.
> I would suggest that we add the revision number for both trunk and branch
> as comments in the issue. That will help us to track it easier.
>
> Or does anybody have a better idea?
>
> But I think it is the responsibility of the developer to fix it in both
> trees. Fix in trunk and merge in branch.
>
> Juergen
>  >
> > 2012/7/5 Li Feng Wang <phoenix.wanglf@gmail.com>
> >
> > > Hi, all,
> > > I am verifying some resolved 3.4.1 release blocker defects. Some fixe=
d
> on
> > > trunk, some fixed on branch, some fixed on both trunk and branch
> > >
> > > I usually verify defects on stream, which fixed code exist, then clos=
e
> > > it.
> > >
> > > But I think tester can close defect, that must fixed on trunk.
> > >
> > > I want to confirm when tester close release blocker defect, Do we nee=
d
> > > to ensure the defect fixed on trunk?
> > > or Tester can close defect after verified defect on branch, then need
> > > verfiy all release blocker defects on trunk before release?
> > >
> > >
> > > --
> > > Best Wishes, LiFeng Wang
> > >
> >
> >
> >
> >
> > --
> >
> >
> > Thanks & Best Regards, Yan Ji
>
>


--=20
Best Wishes, LiFeng Wang

--e89a8f642e98f36c6904c41003b5--