You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Li Feng Wang <ph...@gmail.com> on 2012/07/05 05:18:13 UTC

[QA]When tester can close release blocker defect

Hi, all,
  I am verifying some resolved 3.4.1 release blocker defects. Some fixed on
trunk, some fixed on branch, some fixed on both trunk and branch

  I usually verify defects on stream, which fixed code exist,  then close
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 need
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

Re: [QA]When tester can close release blocker defect

Posted by Herbert Duerr <hd...@apache.org>.
Hi,

On 05.07.2012 10:32, Li Feng Wang wrote:
> Support to link to SVN automatically.
>
> In Jira, developer need submit code to svn with Defect ID in notes, then
> Jira will have svn item automatic link to svn revision info.
> Bugzilla may provide this function after integrating with svn.

Yes, that's a good point. This should be possible for bugzilla too. 
After discussing the idea of svn-bugzilla integration on the asfinfra 
chat I opened the JIRA wish https://issues.apache.org/jira/browse/INFRA-5004

Herbert

Re: [QA]When tester can close release blocker defect

Posted by Li Feng Wang <ph...@gmail.com>.
Support to link to SVN automatically.

In Jira, developer need submit code to svn with Defect ID in notes, then
Jira will have svn item automatic link to svn revision info.
Bugzilla may provide this function after integrating with svn.


2012/7/5 Herbert Duerr <hd...@apache.org>

> On 05.07.2012 08:05, Jürgen Schmidt wrote:
>
>> 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 and
>>> 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
>> merge it in the branch on demand if it is a blocker issue.
>>
>
> +1
>
>
> 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?
>>
>
> +1
> And if issue references in commit messages could be reliably parsed then
> this manual copy+paste step could eventually be automated. Please see the
> mailing list thread "Commit message summaries" for more details on this and
> related ideas (http://markmail.org/thread/**mv4arv432bjdkkqm<http://markmail.org/thread/mv4arv432bjdkkqm>
> ).
>
> Herbert
>



-- 
Best Wishes, LiFeng Wang

Re: [QA]When tester can close release blocker defect

Posted by Herbert Duerr <hd...@apache.org>.
On 05.07.2012 08:05, Jürgen Schmidt wrote:
> 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 and
>> 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 merge it in the branch on demand if it is a blocker issue.

+1

> 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?

+1
And if issue references in commit messages could be reliably parsed then 
this manual copy+paste step could eventually be automated. Please see 
the mailing list thread "Commit message summaries" for more details on 
this and related ideas (http://markmail.org/thread/mv4arv432bjdkkqm).

Herbert

Re: [QA]When tester can close release blocker defect

Posted by Li Feng Wang <ph...@gmail.com>.
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ürgen Schmidt <jo...@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 and
> > 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 merge
> 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 <ph...@gmail.com>
> >
> > > Hi, all,
> > > I am verifying some resolved 3.4.1 release blocker defects. Some fixed
> on
> > > trunk, some fixed on branch, some fixed on both trunk and branch
> > >
> > > I usually verify defects on stream, which fixed code exist, then close
> > > 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 need
> > > 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
>
>


-- 
Best Wishes, LiFeng Wang

Re: [QA]When tester can close release blocker defect

Posted by Jürgen Schmidt <jo...@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 and
> 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 merge 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 <ph...@gmail.com>
> 
> > Hi, all,
> > I am verifying some resolved 3.4.1 release blocker defects. Some fixed on
> > trunk, some fixed on branch, some fixed on both trunk and branch
> > 
> > I usually verify defects on stream, which fixed code exist, then close
> > 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 need
> > 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 


Re: [QA]When tester can close release blocker defect

Posted by Ji Yan <ya...@gmail.com>.
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 and
trunk stream.

2012/7/5 Li Feng Wang <ph...@gmail.com>

> Hi, all,
>   I am verifying some resolved 3.4.1 release blocker defects. Some fixed on
> trunk, some fixed on branch, some fixed on both trunk and branch
>
>   I usually verify defects on stream, which fixed code exist,  then close
> 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 need
> 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