You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Andrew Wang <an...@cloudera.com> on 2016/08/30 01:57:09 UTC
[REMINDER] How to set fix versions when committing
Hi all,
I finished the bulk fix version update and just rebranched
branch-3.0.0-alpha1 off of trunk. So, a reminder that the procedure for
setting fix versions has changed slightly from before.
Everything is fully detailed here, the example in particular should help
clarify things:
https://hadoop.apache.org/versioning.html
The short of it though is that if a JIRA is going into trunk or
branch-3.0.0-alpha1, it should also have a 3.0.0-alpha1 or 3.0.0-alpha2
fixVersion set.
Thanks,
Andrew
Re: [REMINDER] How to set fix versions when committing
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping,
On Tue, Aug 30, 2016 at 4:30 AM, Junping Du <jd...@hortonworks.com> wrote:
> Hi Andrew and all,
> Thanks for the notice on the change. I still concern this rule change
> may cause some confusion from conflicting against our previous rule - no
> need to set trunk version if it is landing on 2.x branch. As we can see,
> there are 4 cases of version setting for JIRA landing on trunk and branch-2
> now:
> 1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
> 2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
> 3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1
> cut off.
> 4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1
> cut off
>
> Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our
> rule change here and hard to differentiate unless we want to mark all
> previous JIRA with fixed version for 2.x only to include
> 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this
> should be our option.
>
I believe (1) was handled by the bulk fix version update I did. It added
the 3.0.0-alpha1 fix version for all JIRAs committed to trunk after the
release of 2.7.0. I filtered out branch-2 only commits based on git log.
(2) was addressed by rebranching branch-3.0.0-alpha1 after the bulk fix
version update. It should be easy to track mistakes via a JIRA query
similar to the one used to do the bulk fix version update. That code is all
posted on my github: https://github.com/umbrant/jira-update
Best,
Andrew
Re: [REMINDER] How to set fix versions when committing
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping,
On Tue, Aug 30, 2016 at 4:30 AM, Junping Du <jd...@hortonworks.com> wrote:
> Hi Andrew and all,
> Thanks for the notice on the change. I still concern this rule change
> may cause some confusion from conflicting against our previous rule - no
> need to set trunk version if it is landing on 2.x branch. As we can see,
> there are 4 cases of version setting for JIRA landing on trunk and branch-2
> now:
> 1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
> 2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
> 3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1
> cut off.
> 4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1
> cut off
>
> Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our
> rule change here and hard to differentiate unless we want to mark all
> previous JIRA with fixed version for 2.x only to include
> 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this
> should be our option.
>
I believe (1) was handled by the bulk fix version update I did. It added
the 3.0.0-alpha1 fix version for all JIRAs committed to trunk after the
release of 2.7.0. I filtered out branch-2 only commits based on git log.
(2) was addressed by rebranching branch-3.0.0-alpha1 after the bulk fix
version update. It should be easy to track mistakes via a JIRA query
similar to the one used to do the bulk fix version update. That code is all
posted on my github: https://github.com/umbrant/jira-update
Best,
Andrew
Re: [REMINDER] How to set fix versions when committing
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping,
On Tue, Aug 30, 2016 at 4:30 AM, Junping Du <jd...@hortonworks.com> wrote:
> Hi Andrew and all,
> Thanks for the notice on the change. I still concern this rule change
> may cause some confusion from conflicting against our previous rule - no
> need to set trunk version if it is landing on 2.x branch. As we can see,
> there are 4 cases of version setting for JIRA landing on trunk and branch-2
> now:
> 1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
> 2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
> 3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1
> cut off.
> 4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1
> cut off
>
> Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our
> rule change here and hard to differentiate unless we want to mark all
> previous JIRA with fixed version for 2.x only to include
> 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this
> should be our option.
>
I believe (1) was handled by the bulk fix version update I did. It added
the 3.0.0-alpha1 fix version for all JIRAs committed to trunk after the
release of 2.7.0. I filtered out branch-2 only commits based on git log.
(2) was addressed by rebranching branch-3.0.0-alpha1 after the bulk fix
version update. It should be easy to track mistakes via a JIRA query
similar to the one used to do the bulk fix version update. That code is all
posted on my github: https://github.com/umbrant/jira-update
Best,
Andrew
Re: [REMINDER] How to set fix versions when committing
Posted by Andrew Wang <an...@cloudera.com>.
Hi Junping,
On Tue, Aug 30, 2016 at 4:30 AM, Junping Du <jd...@hortonworks.com> wrote:
> Hi Andrew and all,
> Thanks for the notice on the change. I still concern this rule change
> may cause some confusion from conflicting against our previous rule - no
> need to set trunk version if it is landing on 2.x branch. As we can see,
> there are 4 cases of version setting for JIRA landing on trunk and branch-2
> now:
> 1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
> 2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
> 3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1
> cut off.
> 4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1
> cut off
>
> Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our
> rule change here and hard to differentiate unless we want to mark all
> previous JIRA with fixed version for 2.x only to include
> 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this
> should be our option.
>
I believe (1) was handled by the bulk fix version update I did. It added
the 3.0.0-alpha1 fix version for all JIRAs committed to trunk after the
release of 2.7.0. I filtered out branch-2 only commits based on git log.
(2) was addressed by rebranching branch-3.0.0-alpha1 after the bulk fix
version update. It should be easy to track mistakes via a JIRA query
similar to the one used to do the bulk fix version update. That code is all
posted on my github: https://github.com/umbrant/jira-update
Best,
Andrew
Re: [REMINDER] How to set fix versions when committing
Posted by Junping Du <jd...@hortonworks.com>.
Hi Andrew and all,
Thanks for the notice on the change. I still concern this rule change may cause some confusion from conflicting against our previous rule - no need to set trunk version if it is landing on 2.x branch. As we can see, there are 4 cases of version setting for JIRA landing on trunk and branch-2 now:
1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1 cut off.
4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1 cut off
Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our rule change here and hard to differentiate unless we want to mark all previous JIRA with fixed version for 2.x only to include 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this should be our option.
Or, my preference is: we should update our rule here a bit to assume all JIRA marked fixed version to 2.x only get landed to 3.0.0-alpha1 but in the meanwhile, we monitor all JIRAs come after 3.0.0-alpha1 cut off to include 3.0.0-alpha2 (or latest trunk version).
Thoughts?
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Tuesday, August 30, 2016 2:57 AM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: [REMINDER] How to set fix versions when committing
Hi all,
I finished the bulk fix version update and just rebranched
branch-3.0.0-alpha1 off of trunk. So, a reminder that the procedure for
setting fix versions has changed slightly from before.
Everything is fully detailed here, the example in particular should help
clarify things:
https://hadoop.apache.org/versioning.html
The short of it though is that if a JIRA is going into trunk or
branch-3.0.0-alpha1, it should also have a 3.0.0-alpha1 or 3.0.0-alpha2
fixVersion set.
Thanks,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [REMINDER] How to set fix versions when committing
Posted by Junping Du <jd...@hortonworks.com>.
Hi Andrew and all,
Thanks for the notice on the change. I still concern this rule change may cause some confusion from conflicting against our previous rule - no need to set trunk version if it is landing on 2.x branch. As we can see, there are 4 cases of version setting for JIRA landing on trunk and branch-2 now:
1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1 cut off.
4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1 cut off
Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our rule change here and hard to differentiate unless we want to mark all previous JIRA with fixed version for 2.x only to include 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this should be our option.
Or, my preference is: we should update our rule here a bit to assume all JIRA marked fixed version to 2.x only get landed to 3.0.0-alpha1 but in the meanwhile, we monitor all JIRAs come after 3.0.0-alpha1 cut off to include 3.0.0-alpha2 (or latest trunk version).
Thoughts?
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Tuesday, August 30, 2016 2:57 AM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: [REMINDER] How to set fix versions when committing
Hi all,
I finished the bulk fix version update and just rebranched
branch-3.0.0-alpha1 off of trunk. So, a reminder that the procedure for
setting fix versions has changed slightly from before.
Everything is fully detailed here, the example in particular should help
clarify things:
https://hadoop.apache.org/versioning.html
The short of it though is that if a JIRA is going into trunk or
branch-3.0.0-alpha1, it should also have a 3.0.0-alpha1 or 3.0.0-alpha2
fixVersion set.
Thanks,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [REMINDER] How to set fix versions when committing
Posted by Junping Du <jd...@hortonworks.com>.
Hi Andrew and all,
Thanks for the notice on the change. I still concern this rule change may cause some confusion from conflicting against our previous rule - no need to set trunk version if it is landing on 2.x branch. As we can see, there are 4 cases of version setting for JIRA landing on trunk and branch-2 now:
1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1 cut off.
4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1 cut off
Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our rule change here and hard to differentiate unless we want to mark all previous JIRA with fixed version for 2.x only to include 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this should be our option.
Or, my preference is: we should update our rule here a bit to assume all JIRA marked fixed version to 2.x only get landed to 3.0.0-alpha1 but in the meanwhile, we monitor all JIRAs come after 3.0.0-alpha1 cut off to include 3.0.0-alpha2 (or latest trunk version).
Thoughts?
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Tuesday, August 30, 2016 2:57 AM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: [REMINDER] How to set fix versions when committing
Hi all,
I finished the bulk fix version update and just rebranched
branch-3.0.0-alpha1 off of trunk. So, a reminder that the procedure for
setting fix versions has changed slightly from before.
Everything is fully detailed here, the example in particular should help
clarify things:
https://hadoop.apache.org/versioning.html
The short of it though is that if a JIRA is going into trunk or
branch-3.0.0-alpha1, it should also have a 3.0.0-alpha1 or 3.0.0-alpha2
fixVersion set.
Thanks,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [REMINDER] How to set fix versions when committing
Posted by Junping Du <jd...@hortonworks.com>.
Hi Andrew and all,
Thanks for the notice on the change. I still concern this rule change may cause some confusion from conflicting against our previous rule - no need to set trunk version if it is landing on 2.x branch. As we can see, there are 4 cases of version setting for JIRA landing on trunk and branch-2 now:
1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1 cut off.
4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1 cut off
Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our rule change here and hard to differentiate unless we want to mark all previous JIRA with fixed version for 2.x only to include 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this should be our option.
Or, my preference is: we should update our rule here a bit to assume all JIRA marked fixed version to 2.x only get landed to 3.0.0-alpha1 but in the meanwhile, we monitor all JIRAs come after 3.0.0-alpha1 cut off to include 3.0.0-alpha2 (or latest trunk version).
Thoughts?
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Tuesday, August 30, 2016 2:57 AM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: [REMINDER] How to set fix versions when committing
Hi all,
I finished the bulk fix version update and just rebranched
branch-3.0.0-alpha1 off of trunk. So, a reminder that the procedure for
setting fix versions has changed slightly from before.
Everything is fully detailed here, the example in particular should help
clarify things:
https://hadoop.apache.org/versioning.html
The short of it though is that if a JIRA is going into trunk or
branch-3.0.0-alpha1, it should also have a 3.0.0-alpha1 or 3.0.0-alpha2
fixVersion set.
Thanks,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org