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" <[email protected]> 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 <[email protected]> >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" <[email protected]> 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 <[email protected]>: >>>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <[email protected]> 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 <[email protected]> >>> >> >
