You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yetus.apache.org by Sean Busbey <bu...@apache.org> on 2016/04/04 02:36:29 UTC
[VOTE] Apache Yetus 0.2.1-RC1
Hi Folks!
I am pleased to announce the first release candidate for Apache Yetus 0.2.1
Artifacts are available:
https://dist.apache.org/repos/dist/dev/yetus/0.2.1-RC1/
As of this vote the relevant md5 hashes are:
427b0e685dca43f51a43ef45f49237ae CHANGES.md
17ec8e87a994b3ee86db7b62f4e827fd RELEASENOTES.md
479d71d3347634c348d43dc414cdbb3d yetus-0.2.1-bin.tar.gz
35a24fa81b1cdd4966d7d77e1dd767f1 yetus-0.2.1-src.tar.gz
Source repository commit:
07cfe2ece72e382d2a9df258bdbaab22e6e8624b
Our KEYS file is at: https://dist.apache.org/repos/dist/release/yetus/KEYS
All artifacts are signed with my key (0D80DB7C)
This is a maintenance release meant to fix the following errors in 0.2.0:
* [YETUS-334] - mvn dependency ordering generates duplicates
Please see the list of all resolved issues in the JIRA release notes:
http://s.apache.org/yetus-0.2.1-jira
Please take a few minutes to verify the release[1] and vote on releasing it:
[ ] +1 Release this package as Apache Yetus 0.2.1
[ ] +0 no opinion
[ ] -1 Do not release this package because...
Vote will be subject to Majority Approval[2] and will close at 1:00AM
UTC on Wednesday, Apr 7th, 2016[3].
[1]: http://yetus.apache.org/contribute/releases/#verification
[2]: https://www.apache.org/foundation/glossary.html#MajorityApproval
[3]: to find this in your local timezone see:
http://s.apache.org/yetus-0.2.1-rc1-close
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Kengo Seki <se...@apache.org>.
> could you start a new thread that summarizes what we still need to do for that release?
Sure, I'll post it today!
2016-04-09 0:24 GMT+09:00 Chris Nauroth <cn...@hortonworks.com>:
> Thanks for the summary, Sean.
>
> My apologies, but it appears I missed the past several days of emails to
> the dev list. I definitely see the [RESULT] thread now when I look in the
> mail archives, so it must be a problem on my end.
>
> I'll watch out for the next RC and participate on that one if I'm here.
>
> --Chris Nauroth
>
>
>
>
> On 4/7/16, 8:21 PM, "Sean Busbey" <bu...@apache.org> wrote:
>
>>Yep!
>>
>>Kengo and I agreed to not worry about the prior release information
>>for the 0.2.1 release and he's going to file a follow-on jira for us
>>to copy all of the release info from master (without maintaining
>>specific commits) as a part of our release process in the future.
>>
>>After that, he changed his vote to +1. Later I voted +1 and yesterday
>>evening Allen did as well. The vote has now closed, with just enough
>>votes to pass.
>>
>>I'm not sure where Kengo is on 0.3.0 RCs. Kengo, could you start a new
>>thread that summarizes what we still need to do for that release?
>>
>>On Thu, Apr 7, 2016 at 3:49 PM, Chris Nauroth <cn...@hortonworks.com>
>>wrote:
>>> Sean and Kengo, did the two of you reach agreement on how to proceed
>>>with
>>> this RC? I had been holding off my own verification and voting due to
>>>the
>>> open question.
>>>
>>> I'm available to verify an RC tonight and tomorrow. After Friday, 4/8
>>>at
>>> 3 PM PST, I'll be unavailable through at least 4/18.
>>>
>>> --Chris Nauroth
>>>
>>>
>>>
>>>
>>> On 4/5/16, 4:36 AM, "Kengo Seki" <se...@apache.org> wrote:
>>>
>>>>> For example, Say 0.2.2 is made after we've had a 0.3.0 release.
>>>>> Would I backport both the change for 0.2.1's release and 0.3.0's?
>>>>> When 0.3.1 comes out do I backport the notice for 0.2.2?
>>>>
>>>>Sorry for not explaining enough, I didn't intend to backport 0.3.x
>>>>into 0.2.x. I simply thought it might be natural that 0.2.1 contains
>>>>documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0.
>>>>
>>>>But in this case, the difference between 0.2.0 and 0.2.1 is very small
>>>>and obvious from the changelog. In addition, users can check online
>>>>document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for
>>>>this RC now.
>>>>
>>>>> On the other hand, we could just have a step of copying the files that
>>>>> change with a successful release directly from then-current master.
>>>>> That would get all of the changes without needing to go searching for
>>>>> the individual commits. HBase does this for docs and it works okay.
>>>>
>>>>That sounds good to me. I'll file it as a JIRA later.
>>>>
>>>>2016-04-05 6:22 GMT+09:00 Sean Busbey <bu...@apache.org>:
>>>>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
>>>>>> I'm +0 for now.
>>>>>> My concern is that YETUS-318-website.patch seems not to be included
>>>>>> this RC. Should we merge this?
>>>>>> If it's unnecessary, I'm +1 (binding). I checked the followings:
>>>>>>
>>>>>
>>>>>
>>>>> ... interesting. This comes down to what we want in our release
>>>>> process, I think. The post-release-vote website changes always go into
>>>>> some future minor release, by virtue of our current instructions. That
>>>>> means if we want to be able to cut maintenance releases off of the
>>>>> prior minor release we have to either
>>>>>
>>>>> 1) accept that you can't build a correct website off of the
>>>>> maintenance release source
>>>>>
>>>>> 2) backport needed website changes onto the maintenance branch
>>>>>
>>>>> I lean towards #1 just as a matter of logistics. For example, Say
>>>>> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both
>>>>> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
>>>>> backport the notice for 0.2.2? Do we do this for every release that's
>>>>> happened since the last maintenance release? Are we setting ourselves
>>>>> up for an ever-increasing amount of work then?
>>>>>
>>>>> On the other hand, we could just have a step of copying the files that
>>>>> change with a successful release directly from then-current master.
>>>>> That would get all of the changes without needing to go searching for
>>>>> the individual commits. HBase does this for docs and it works okay.
>>>>
>>>>
>>>>
>>>>--
>>>>Kengo Seki <se...@apache.org>
>>>>
>>>
>>
>
--
Kengo Seki <se...@apache.org>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Sean Busbey <bu...@apache.org>.
Could someone do a quick review of the website changes on YETUS-344?
It's blocking the announcement emails.
On Fri, Apr 8, 2016 at 10:24 AM, Chris Nauroth <cn...@hortonworks.com> wrote:
> Thanks for the summary, Sean.
>
> My apologies, but it appears I missed the past several days of emails to
> the dev list. I definitely see the [RESULT] thread now when I look in the
> mail archives, so it must be a problem on my end.
>
> I'll watch out for the next RC and participate on that one if I'm here.
>
> --Chris Nauroth
>
>
>
>
> On 4/7/16, 8:21 PM, "Sean Busbey" <bu...@apache.org> wrote:
>
>>Yep!
>>
>>Kengo and I agreed to not worry about the prior release information
>>for the 0.2.1 release and he's going to file a follow-on jira for us
>>to copy all of the release info from master (without maintaining
>>specific commits) as a part of our release process in the future.
>>
>>After that, he changed his vote to +1. Later I voted +1 and yesterday
>>evening Allen did as well. The vote has now closed, with just enough
>>votes to pass.
>>
>>I'm not sure where Kengo is on 0.3.0 RCs. Kengo, could you start a new
>>thread that summarizes what we still need to do for that release?
>>
>>On Thu, Apr 7, 2016 at 3:49 PM, Chris Nauroth <cn...@hortonworks.com>
>>wrote:
>>> Sean and Kengo, did the two of you reach agreement on how to proceed
>>>with
>>> this RC? I had been holding off my own verification and voting due to
>>>the
>>> open question.
>>>
>>> I'm available to verify an RC tonight and tomorrow. After Friday, 4/8
>>>at
>>> 3 PM PST, I'll be unavailable through at least 4/18.
>>>
>>> --Chris Nauroth
>>>
>>>
>>>
>>>
>>> On 4/5/16, 4:36 AM, "Kengo Seki" <se...@apache.org> wrote:
>>>
>>>>> For example, Say 0.2.2 is made after we've had a 0.3.0 release.
>>>>> Would I backport both the change for 0.2.1's release and 0.3.0's?
>>>>> When 0.3.1 comes out do I backport the notice for 0.2.2?
>>>>
>>>>Sorry for not explaining enough, I didn't intend to backport 0.3.x
>>>>into 0.2.x. I simply thought it might be natural that 0.2.1 contains
>>>>documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0.
>>>>
>>>>But in this case, the difference between 0.2.0 and 0.2.1 is very small
>>>>and obvious from the changelog. In addition, users can check online
>>>>document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for
>>>>this RC now.
>>>>
>>>>> On the other hand, we could just have a step of copying the files that
>>>>> change with a successful release directly from then-current master.
>>>>> That would get all of the changes without needing to go searching for
>>>>> the individual commits. HBase does this for docs and it works okay.
>>>>
>>>>That sounds good to me. I'll file it as a JIRA later.
>>>>
>>>>2016-04-05 6:22 GMT+09:00 Sean Busbey <bu...@apache.org>:
>>>>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
>>>>>> I'm +0 for now.
>>>>>> My concern is that YETUS-318-website.patch seems not to be included
>>>>>> this RC. Should we merge this?
>>>>>> If it's unnecessary, I'm +1 (binding). I checked the followings:
>>>>>>
>>>>>
>>>>>
>>>>> ... interesting. This comes down to what we want in our release
>>>>> process, I think. The post-release-vote website changes always go into
>>>>> some future minor release, by virtue of our current instructions. That
>>>>> means if we want to be able to cut maintenance releases off of the
>>>>> prior minor release we have to either
>>>>>
>>>>> 1) accept that you can't build a correct website off of the
>>>>> maintenance release source
>>>>>
>>>>> 2) backport needed website changes onto the maintenance branch
>>>>>
>>>>> I lean towards #1 just as a matter of logistics. For example, Say
>>>>> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both
>>>>> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
>>>>> backport the notice for 0.2.2? Do we do this for every release that's
>>>>> happened since the last maintenance release? Are we setting ourselves
>>>>> up for an ever-increasing amount of work then?
>>>>>
>>>>> On the other hand, we could just have a step of copying the files that
>>>>> change with a successful release directly from then-current master.
>>>>> That would get all of the changes without needing to go searching for
>>>>> the individual commits. HBase does this for docs and it works okay.
>>>>
>>>>
>>>>
>>>>--
>>>>Kengo Seki <se...@apache.org>
>>>>
>>>
>>
>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Chris Nauroth <cn...@hortonworks.com>.
Thanks for the summary, Sean.
My apologies, but it appears I missed the past several days of emails to
the dev list. I definitely see the [RESULT] thread now when I look in the
mail archives, so it must be a problem on my end.
I'll watch out for the next RC and participate on that one if I'm here.
--Chris Nauroth
On 4/7/16, 8:21 PM, "Sean Busbey" <bu...@apache.org> wrote:
>Yep!
>
>Kengo and I agreed to not worry about the prior release information
>for the 0.2.1 release and he's going to file a follow-on jira for us
>to copy all of the release info from master (without maintaining
>specific commits) as a part of our release process in the future.
>
>After that, he changed his vote to +1. Later I voted +1 and yesterday
>evening Allen did as well. The vote has now closed, with just enough
>votes to pass.
>
>I'm not sure where Kengo is on 0.3.0 RCs. Kengo, could you start a new
>thread that summarizes what we still need to do for that release?
>
>On Thu, Apr 7, 2016 at 3:49 PM, Chris Nauroth <cn...@hortonworks.com>
>wrote:
>> Sean and Kengo, did the two of you reach agreement on how to proceed
>>with
>> this RC? I had been holding off my own verification and voting due to
>>the
>> open question.
>>
>> I'm available to verify an RC tonight and tomorrow. After Friday, 4/8
>>at
>> 3 PM PST, I'll be unavailable through at least 4/18.
>>
>> --Chris Nauroth
>>
>>
>>
>>
>> On 4/5/16, 4:36 AM, "Kengo Seki" <se...@apache.org> wrote:
>>
>>>> For example, Say 0.2.2 is made after we've had a 0.3.0 release.
>>>> Would I backport both the change for 0.2.1's release and 0.3.0's?
>>>> When 0.3.1 comes out do I backport the notice for 0.2.2?
>>>
>>>Sorry for not explaining enough, I didn't intend to backport 0.3.x
>>>into 0.2.x. I simply thought it might be natural that 0.2.1 contains
>>>documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0.
>>>
>>>But in this case, the difference between 0.2.0 and 0.2.1 is very small
>>>and obvious from the changelog. In addition, users can check online
>>>document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for
>>>this RC now.
>>>
>>>> On the other hand, we could just have a step of copying the files that
>>>> change with a successful release directly from then-current master.
>>>> That would get all of the changes without needing to go searching for
>>>> the individual commits. HBase does this for docs and it works okay.
>>>
>>>That sounds good to me. I'll file it as a JIRA later.
>>>
>>>2016-04-05 6:22 GMT+09:00 Sean Busbey <bu...@apache.org>:
>>>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
>>>>> I'm +0 for now.
>>>>> My concern is that YETUS-318-website.patch seems not to be included
>>>>> this RC. Should we merge this?
>>>>> If it's unnecessary, I'm +1 (binding). I checked the followings:
>>>>>
>>>>
>>>>
>>>> ... interesting. This comes down to what we want in our release
>>>> process, I think. The post-release-vote website changes always go into
>>>> some future minor release, by virtue of our current instructions. That
>>>> means if we want to be able to cut maintenance releases off of the
>>>> prior minor release we have to either
>>>>
>>>> 1) accept that you can't build a correct website off of the
>>>> maintenance release source
>>>>
>>>> 2) backport needed website changes onto the maintenance branch
>>>>
>>>> I lean towards #1 just as a matter of logistics. For example, Say
>>>> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both
>>>> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
>>>> backport the notice for 0.2.2? Do we do this for every release that's
>>>> happened since the last maintenance release? Are we setting ourselves
>>>> up for an ever-increasing amount of work then?
>>>>
>>>> On the other hand, we could just have a step of copying the files that
>>>> change with a successful release directly from then-current master.
>>>> That would get all of the changes without needing to go searching for
>>>> the individual commits. HBase does this for docs and it works okay.
>>>
>>>
>>>
>>>--
>>>Kengo Seki <se...@apache.org>
>>>
>>
>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Sean Busbey <bu...@apache.org>.
Yep!
Kengo and I agreed to not worry about the prior release information
for the 0.2.1 release and he's going to file a follow-on jira for us
to copy all of the release info from master (without maintaining
specific commits) as a part of our release process in the future.
After that, he changed his vote to +1. Later I voted +1 and yesterday
evening Allen did as well. The vote has now closed, with just enough
votes to pass.
I'm not sure where Kengo is on 0.3.0 RCs. Kengo, could you start a new
thread that summarizes what we still need to do for that release?
On Thu, Apr 7, 2016 at 3:49 PM, Chris Nauroth <cn...@hortonworks.com> wrote:
> Sean and Kengo, did the two of you reach agreement on how to proceed with
> this RC? I had been holding off my own verification and voting due to the
> open question.
>
> I'm available to verify an RC tonight and tomorrow. After Friday, 4/8 at
> 3 PM PST, I'll be unavailable through at least 4/18.
>
> --Chris Nauroth
>
>
>
>
> On 4/5/16, 4:36 AM, "Kengo Seki" <se...@apache.org> wrote:
>
>>> For example, Say 0.2.2 is made after we've had a 0.3.0 release.
>>> Would I backport both the change for 0.2.1's release and 0.3.0's?
>>> When 0.3.1 comes out do I backport the notice for 0.2.2?
>>
>>Sorry for not explaining enough, I didn't intend to backport 0.3.x
>>into 0.2.x. I simply thought it might be natural that 0.2.1 contains
>>documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0.
>>
>>But in this case, the difference between 0.2.0 and 0.2.1 is very small
>>and obvious from the changelog. In addition, users can check online
>>document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for
>>this RC now.
>>
>>> On the other hand, we could just have a step of copying the files that
>>> change with a successful release directly from then-current master.
>>> That would get all of the changes without needing to go searching for
>>> the individual commits. HBase does this for docs and it works okay.
>>
>>That sounds good to me. I'll file it as a JIRA later.
>>
>>2016-04-05 6:22 GMT+09:00 Sean Busbey <bu...@apache.org>:
>>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
>>>> I'm +0 for now.
>>>> My concern is that YETUS-318-website.patch seems not to be included
>>>> this RC. Should we merge this?
>>>> If it's unnecessary, I'm +1 (binding). I checked the followings:
>>>>
>>>
>>>
>>> ... interesting. This comes down to what we want in our release
>>> process, I think. The post-release-vote website changes always go into
>>> some future minor release, by virtue of our current instructions. That
>>> means if we want to be able to cut maintenance releases off of the
>>> prior minor release we have to either
>>>
>>> 1) accept that you can't build a correct website off of the
>>> maintenance release source
>>>
>>> 2) backport needed website changes onto the maintenance branch
>>>
>>> I lean towards #1 just as a matter of logistics. For example, Say
>>> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both
>>> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
>>> backport the notice for 0.2.2? Do we do this for every release that's
>>> happened since the last maintenance release? Are we setting ourselves
>>> up for an ever-increasing amount of work then?
>>>
>>> On the other hand, we could just have a step of copying the files that
>>> change with a successful release directly from then-current master.
>>> That would get all of the changes without needing to go searching for
>>> the individual commits. HBase does this for docs and it works okay.
>>
>>
>>
>>--
>>Kengo Seki <se...@apache.org>
>>
>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Chris Nauroth <cn...@hortonworks.com>.
Sean and Kengo, did the two of you reach agreement on how to proceed with
this RC? I had been holding off my own verification and voting due to the
open question.
I'm available to verify an RC tonight and tomorrow. After Friday, 4/8 at
3 PM PST, I'll be unavailable through at least 4/18.
--Chris Nauroth
On 4/5/16, 4:36 AM, "Kengo Seki" <se...@apache.org> wrote:
>> For example, Say 0.2.2 is made after we've had a 0.3.0 release.
>> Would I backport both the change for 0.2.1's release and 0.3.0's?
>> When 0.3.1 comes out do I backport the notice for 0.2.2?
>
>Sorry for not explaining enough, I didn't intend to backport 0.3.x
>into 0.2.x. I simply thought it might be natural that 0.2.1 contains
>documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0.
>
>But in this case, the difference between 0.2.0 and 0.2.1 is very small
>and obvious from the changelog. In addition, users can check online
>document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for
>this RC now.
>
>> On the other hand, we could just have a step of copying the files that
>> change with a successful release directly from then-current master.
>> That would get all of the changes without needing to go searching for
>> the individual commits. HBase does this for docs and it works okay.
>
>That sounds good to me. I'll file it as a JIRA later.
>
>2016-04-05 6:22 GMT+09:00 Sean Busbey <bu...@apache.org>:
>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
>>> I'm +0 for now.
>>> My concern is that YETUS-318-website.patch seems not to be included
>>> this RC. Should we merge this?
>>> If it's unnecessary, I'm +1 (binding). I checked the followings:
>>>
>>
>>
>> ... interesting. This comes down to what we want in our release
>> process, I think. The post-release-vote website changes always go into
>> some future minor release, by virtue of our current instructions. That
>> means if we want to be able to cut maintenance releases off of the
>> prior minor release we have to either
>>
>> 1) accept that you can't build a correct website off of the
>> maintenance release source
>>
>> 2) backport needed website changes onto the maintenance branch
>>
>> I lean towards #1 just as a matter of logistics. For example, Say
>> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both
>> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
>> backport the notice for 0.2.2? Do we do this for every release that's
>> happened since the last maintenance release? Are we setting ourselves
>> up for an ever-increasing amount of work then?
>>
>> On the other hand, we could just have a step of copying the files that
>> change with a successful release directly from then-current master.
>> That would get all of the changes without needing to go searching for
>> the individual commits. HBase does this for docs and it works okay.
>
>
>
>--
>Kengo Seki <se...@apache.org>
>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Kengo Seki <se...@apache.org>.
> For example, Say 0.2.2 is made after we've had a 0.3.0 release.
> Would I backport both the change for 0.2.1's release and 0.3.0's?
> When 0.3.1 comes out do I backport the notice for 0.2.2?
Sorry for not explaining enough, I didn't intend to backport 0.3.x
into 0.2.x. I simply thought it might be natural that 0.2.1 contains
documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0.
But in this case, the difference between 0.2.0 and 0.2.1 is very small
and obvious from the changelog. In addition, users can check online
document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for
this RC now.
> On the other hand, we could just have a step of copying the files that
> change with a successful release directly from then-current master.
> That would get all of the changes without needing to go searching for
> the individual commits. HBase does this for docs and it works okay.
That sounds good to me. I'll file it as a JIRA later.
2016-04-05 6:22 GMT+09:00 Sean Busbey <bu...@apache.org>:
> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
>> I'm +0 for now.
>> My concern is that YETUS-318-website.patch seems not to be included
>> this RC. Should we merge this?
>> If it's unnecessary, I'm +1 (binding). I checked the followings:
>>
>
>
> ... interesting. This comes down to what we want in our release
> process, I think. The post-release-vote website changes always go into
> some future minor release, by virtue of our current instructions. That
> means if we want to be able to cut maintenance releases off of the
> prior minor release we have to either
>
> 1) accept that you can't build a correct website off of the
> maintenance release source
>
> 2) backport needed website changes onto the maintenance branch
>
> I lean towards #1 just as a matter of logistics. For example, Say
> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both
> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
> backport the notice for 0.2.2? Do we do this for every release that's
> happened since the last maintenance release? Are we setting ourselves
> up for an ever-increasing amount of work then?
>
> On the other hand, we could just have a step of copying the files that
> change with a successful release directly from then-current master.
> That would get all of the changes without needing to go searching for
> the individual commits. HBase does this for docs and it works okay.
--
Kengo Seki <se...@apache.org>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Sean Busbey <bu...@apache.org>.
On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <se...@apache.org> wrote:
> I'm +0 for now.
> My concern is that YETUS-318-website.patch seems not to be included
> this RC. Should we merge this?
> If it's unnecessary, I'm +1 (binding). I checked the followings:
>
... interesting. This comes down to what we want in our release
process, I think. The post-release-vote website changes always go into
some future minor release, by virtue of our current instructions. That
means if we want to be able to cut maintenance releases off of the
prior minor release we have to either
1) accept that you can't build a correct website off of the
maintenance release source
2) backport needed website changes onto the maintenance branch
I lean towards #1 just as a matter of logistics. For example, Say
0.2.2 is made after we've had a 0.3.0 release. Would I backport both
the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I
backport the notice for 0.2.2? Do we do this for every release that's
happened since the last maintenance release? Are we setting ourselves
up for an ever-increasing amount of work then?
On the other hand, we could just have a step of copying the files that
change with a successful release directly from then-current master.
That would get all of the changes without needing to go searching for
the individual commits. HBase does this for docs and it works okay.
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Kengo Seki <se...@apache.org>.
I'm +0 for now.
My concern is that YETUS-318-website.patch seems not to be included
this RC. Should we merge this?
If it's unnecessary, I'm +1 (binding). I checked the followings:
- Verified signatures and checksums for all distribution artifacts.
- Reviewed LICENSE and NOTICE.
- Reviewed CHANGES.md and (empty) RELEASENOTES.md.
- Built successfully from source.
- Manually tested test-patch on Hadoop and HBase.
2016-04-04 9:36 GMT+09:00 Sean Busbey <bu...@apache.org>:
>
> Hi Folks!
>
> I am pleased to announce the first release candidate for Apache Yetus 0.2.1
>
> Artifacts are available:
>
> https://dist.apache.org/repos/dist/dev/yetus/0.2.1-RC1/
>
> As of this vote the relevant md5 hashes are:
>
> 427b0e685dca43f51a43ef45f49237ae CHANGES.md
> 17ec8e87a994b3ee86db7b62f4e827fd RELEASENOTES.md
> 479d71d3347634c348d43dc414cdbb3d yetus-0.2.1-bin.tar.gz
> 35a24fa81b1cdd4966d7d77e1dd767f1 yetus-0.2.1-src.tar.gz
>
> Source repository commit:
>
> 07cfe2ece72e382d2a9df258bdbaab22e6e8624b
>
>
> Our KEYS file is at: https://dist.apache.org/repos/dist/release/yetus/KEYS
> All artifacts are signed with my key (0D80DB7C)
>
> This is a maintenance release meant to fix the following errors in 0.2.0:
>
> * [YETUS-334] - mvn dependency ordering generates duplicates
>
> Please see the list of all resolved issues in the JIRA release notes:
>
> http://s.apache.org/yetus-0.2.1-jira
>
> Please take a few minutes to verify the release[1] and vote on releasing it:
>
> [ ] +1 Release this package as Apache Yetus 0.2.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Vote will be subject to Majority Approval[2] and will close at 1:00AM
> UTC on Wednesday, Apr 7th, 2016[3].
>
> [1]: http://yetus.apache.org/contribute/releases/#verification
> [2]: https://www.apache.org/foundation/glossary.html#MajorityApproval
> [3]: to find this in your local timezone see:
> http://s.apache.org/yetus-0.2.1-rc1-close
--
Kengo Seki <se...@apache.org>
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Allen Wittenauer <al...@yahoo.com.INVALID>.
+1
[Sorry I’ve been MIA lately. A lot of stuff going on… which is odd given I’m unemployed. *sigh*]
> On Apr 5, 2016, at 10:42 PM, Sean Busbey <bu...@apache.org> wrote:
>
> Friendly reminder that there are about 19 hours left in this vote.
>
> +1
>
> - checked sigs and sums
> - checked LICENSE/NOTICE
> - checked src matches given commit hash
> - built from source
>
>
> On Sun, Apr 3, 2016 at 5:36 PM, Sean Busbey <bu...@apache.org> wrote:
>> Hi Folks!
>>
>> I am pleased to announce the first release candidate for Apache Yetus 0.2.1
>>
>> Artifacts are available:
>>
>> https://dist.apache.org/repos/dist/dev/yetus/0.2.1-RC1/
>>
>> As of this vote the relevant md5 hashes are:
>>
>> 427b0e685dca43f51a43ef45f49237ae CHANGES.md
>> 17ec8e87a994b3ee86db7b62f4e827fd RELEASENOTES.md
>> 479d71d3347634c348d43dc414cdbb3d yetus-0.2.1-bin.tar.gz
>> 35a24fa81b1cdd4966d7d77e1dd767f1 yetus-0.2.1-src.tar.gz
>>
>> Source repository commit:
>>
>> 07cfe2ece72e382d2a9df258bdbaab22e6e8624b
>>
>>
>> Our KEYS file is at: https://dist.apache.org/repos/dist/release/yetus/KEYS
>> All artifacts are signed with my key (0D80DB7C)
>>
>> This is a maintenance release meant to fix the following errors in 0.2.0:
>>
>> * [YETUS-334] - mvn dependency ordering generates duplicates
>>
>> Please see the list of all resolved issues in the JIRA release notes:
>>
>> http://s.apache.org/yetus-0.2.1-jira
>>
>> Please take a few minutes to verify the release[1] and vote on releasing it:
>>
>> [ ] +1 Release this package as Apache Yetus 0.2.1
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...
>>
>> Vote will be subject to Majority Approval[2] and will close at 1:00AM
>> UTC on Wednesday, Apr 7th, 2016[3].
>>
>> [1]: http://yetus.apache.org/contribute/releases/#verification
>> [2]: https://www.apache.org/foundation/glossary.html#MajorityApproval
>> [3]: to find this in your local timezone see:
>> http://s.apache.org/yetus-0.2.1-rc1-close
Re: [VOTE] Apache Yetus 0.2.1-RC1
Posted by Sean Busbey <bu...@apache.org>.
Friendly reminder that there are about 19 hours left in this vote.
+1
- checked sigs and sums
- checked LICENSE/NOTICE
- checked src matches given commit hash
- built from source
On Sun, Apr 3, 2016 at 5:36 PM, Sean Busbey <bu...@apache.org> wrote:
> Hi Folks!
>
> I am pleased to announce the first release candidate for Apache Yetus 0.2.1
>
> Artifacts are available:
>
> https://dist.apache.org/repos/dist/dev/yetus/0.2.1-RC1/
>
> As of this vote the relevant md5 hashes are:
>
> 427b0e685dca43f51a43ef45f49237ae CHANGES.md
> 17ec8e87a994b3ee86db7b62f4e827fd RELEASENOTES.md
> 479d71d3347634c348d43dc414cdbb3d yetus-0.2.1-bin.tar.gz
> 35a24fa81b1cdd4966d7d77e1dd767f1 yetus-0.2.1-src.tar.gz
>
> Source repository commit:
>
> 07cfe2ece72e382d2a9df258bdbaab22e6e8624b
>
>
> Our KEYS file is at: https://dist.apache.org/repos/dist/release/yetus/KEYS
> All artifacts are signed with my key (0D80DB7C)
>
> This is a maintenance release meant to fix the following errors in 0.2.0:
>
> * [YETUS-334] - mvn dependency ordering generates duplicates
>
> Please see the list of all resolved issues in the JIRA release notes:
>
> http://s.apache.org/yetus-0.2.1-jira
>
> Please take a few minutes to verify the release[1] and vote on releasing it:
>
> [ ] +1 Release this package as Apache Yetus 0.2.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Vote will be subject to Majority Approval[2] and will close at 1:00AM
> UTC on Wednesday, Apr 7th, 2016[3].
>
> [1]: http://yetus.apache.org/contribute/releases/#verification
> [2]: https://www.apache.org/foundation/glossary.html#MajorityApproval
> [3]: to find this in your local timezone see:
> http://s.apache.org/yetus-0.2.1-rc1-close