> 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 <[email protected]>: > 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]> >>>> >>> >> > -- Kengo Seki <[email protected]>
