YARN-10314 also seems to be a blocker. https://issues.apache.org/jira/browse/YARN-10314
We should wait for that as well, should get concluded in a day or two. -Ayush > On 15-Jun-2020, at 7:21 AM, Sheng Liu <liusheng2...@gmail.com> wrote: > > The HADOOP-17046 <https://issues.apache.org/jira/browse/HADOOP-17046> has > been merged :) > > Brahma Reddy Battula <bra...@apache.org> 于2020年6月4日周四 下午10:43写道： > >> Following blocker is pending for 3.3.0 release which is ready for review. >> Mostly we'll have RC soon. >> https://issues.apache.org/jira/browse/HADOOP-17046 >> >> Protobuf dependency was unexpected . >> >>> On Mon, Jun 1, 2020 at 7:11 AM Sheng Liu <liusheng2...@gmail.com> wrote: >>> >>> Hi folks, >>> >>> It looks like the 3.3.0 branch has been created for quite a while. Not >> sure >>> if there is remain block issue that need to be addressed before Hadoop >>> 3.3.0 release publishing, maybe we can bring up to here and move the >>> release forward ? >>> >>> Thank. >>> >>> Brahma Reddy Battula <bra...@apache.org> 于2020年3月25日周三 上午1:55写道： >>> >>>> thanks to all. >>>> >>>> will make this as optional..will update the wiki accordingly. >>>> >>>> On Wed, Mar 18, 2020 at 12:05 AM Vinayakumar B < >> vinayakum...@apache.org> >>>> wrote: >>>> >>>>> Making ARM artifact optional, makes the release process simpler for >> RM >>>> and >>>>> unblocks release process (if there is unavailability of ARM >> resources). >>>>> >>>>> Still there are possible options to collaborate with RM ( as brahma >>>>> mentioned earlier) and provide ARM artifact may be before or after >>> vote. >>>>> If feasible RM can decide to add ARM artifact by collaborating with >>>> @Brahma >>>>> Reddy Battula <bra...@apache.org> or me to get the ARM artifact. >>>>> >>>>> -Vinay >>>>> >>>>> On Tue, Mar 17, 2020 at 11:39 PM Arpit Agarwal >>>>> <aagar...@cloudera.com.invalid> wrote: >>>>> >>>>>> Thanks for the clarification Brahma. Can you update the proposal to >>>> state >>>>>> that it is optional (it may help to put the proposal on cwiki)? >>>>>> >>>>>> Also if we go ahead then the RM documentation should be clear this >> is >>>> an >>>>>> optional step. >>>>>> >>>>>> >>>>>>> On Mar 17, 2020, at 11:06 AM, Brahma Reddy Battula < >>>> bra...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>> Sure, we can't make mandatory while voting and we can upload to >>>>> downloads >>>>>>> once release vote is passed. >>>>>>> >>>>>>> On Tue, 17 Mar 2020 at 11:24 PM, Arpit Agarwal >>>>>>> <aagar...@cloudera.com.invalid> wrote: >>>>>>> >>>>>>>>> Sorry,didn't get you...do you mean, once release voting is >>>>>>>>> processed and upload by RM..? >>>>>>>> >>>>>>>> Yes, that is what I meant. I don’t want us to make more >> mandatory >>>> work >>>>>> for >>>>>>>> the release manager because the job is hard enough already. >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 17, 2020, at 10:46 AM, Brahma Reddy Battula < >>>>> bra...@apache.org> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Sorry,didn't get you...do you mean, once release voting is >>>> processed >>>>>> and >>>>>>>>> upload by RM..? >>>>>>>>> >>>>>>>>> FYI. There is docker image for ARM also which support all >> scripts >>>>>>>>> (createrelease, start-build-env.sh, etc ). >>>>>>>>> >>>>>>>>> https://issues.apache.org/jira/browse/HADOOP-16797 >>>>>>>>> >>>>>>>>> On Tue, Mar 17, 2020 at 10:59 PM Arpit Agarwal >>>>>>>>> <aagar...@cloudera.com.invalid> wrote: >>>>>>>>> >>>>>>>>>> Can ARM binaries be provided after the fact? We cannot >> increase >>>> the >>>>>> RM’s >>>>>>>>>> burden by asking them to generate an extra set of binaries. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Mar 17, 2020, at 10:23 AM, Brahma Reddy Battula < >>>>>> bra...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> + Dev mailing list. >>>>>>>>>>> >>>>>>>>>>> ---------- Forwarded message --------- >>>>>>>>>>> From: Brahma Reddy Battula <bra...@apache.org> >>>>>>>>>>> Date: Tue, Mar 17, 2020 at 10:31 PM >>>>>>>>>>> Subject: Re: [DISCUSS] Hadoop 3.3.0 Release include ARM >> binary >>>>>>>>>>> To: junping_du <junping...@apache.org> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> thanks junping for your reply. >>>>>>>>>>> >>>>>>>>>>> bq. I think most of us in Hadoop community doesn't want >> to >>>>> have >>>>>>>>>> biased >>>>>>>>>>> on ARM or any other platforms. >>>>>>>>>>> >>>>>>>>>>> Yes, release voting will be based on the source >>> code.AFAIK,Binary >>>>> we >>>>>>>> are >>>>>>>>>>> providing for user to easy to download and verify. >>>>>>>>>>> >>>>>>>>>>> bq. The only thing I try to understand is how much >>> complexity >>>>> get >>>>>>>>>>> involved for our RM work. Does that potentially become a >>> blocker >>>>> for >>>>>>>>>> future >>>>>>>>>>> releases? And how we can get rid of this risk. >>>>>>>>>>> >>>>>>>>>>> As I mentioned earlier, RM need to access the ARM machine(it >>> will >>>>> be >>>>>>>>>>> donated and current qbt also using one ARM machine) and build >>> tar >>>>>> using >>>>>>>>>> the >>>>>>>>>>> keys. As it can be common machine, RM can delete his keys >> once >>>>>> release >>>>>>>>>>> approved. >>>>>>>>>>> Can be sorted out as I mentioned earlier.(For accessing the >> ARM >>>>>>>> machine) >>>>>>>>>>> >>>>>>>>>>> bq. If you can list the concrete work that RM need to >> do >>>>> extra >>>>>>>> for >>>>>>>>>>> ARM release, that would help us to better understand. >>>>>>>>>>> >>>>>>>>>>> I can write and update for future reference. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 17, 2020 at 10:41 AM 俊平堵 <junping...@apache.org> >>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Brahma, >>>>>>>>>>>> I think most of us in Hadoop community doesn't want to >> have >>>>> biased >>>>>>>>>> on >>>>>>>>>>>> ARM or any other platforms. >>>>>>>>>>>> The only thing I try to understand is how much complexity >>> get >>>>>>>>>>>> involved for our RM work. Does that potentially become a >>> blocker >>>>> for >>>>>>>>>> future >>>>>>>>>>>> releases? And how we can get rid of this risk. >>>>>>>>>>>> If you can list the concrete work that RM need to do >> extra >>>> for >>>>>> ARM >>>>>>>>>>>> release, that would help us to better understand. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Junping >>>>>>>>>>>> >>>>>>>>>>>> Akira Ajisaka <aajis...@apache.org> 于2020年3月13日周五 >> 上午12:34写道： >>>>>>>>>>>> >>>>>>>>>>>>> If you can provide ARM release for future releases, I'm >> fine >>>> with >>>>>>>> that. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Akira >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 12, 2020 at 9:41 PM Brahma Reddy Battula < >>>>>>>>>> bra...@apache.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> thanks Akira. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently only problem is dedicated ARM for future >> RM.This i >>>>> want >>>>>> to >>>>>>>>>>>>> sort >>>>>>>>>>>>>> out like below,if you've some other,please let me know. >>>>>>>>>>>>>> >>>>>>>>>>>>>> i) Single machine and share cred to future RM ( as we can >>>> delete >>>>>>>> keys >>>>>>>>>>>>> once >>>>>>>>>>>>>> release is over). >>>>>>>>>>>>>> ii) Creating the jenkins project ( may be we need to >> discuss >>>> in >>>>>> the >>>>>>>>>>>>>> board..) >>>>>>>>>>>>>> iii) I can provide ARM release for future releases. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 12, 2020 at 5:14 PM Akira Ajisaka < >>>>>> aajis...@apache.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Brahma, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we cannot do any of your proposed actions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> http://www.apache.org/legal/release-policy.html#owned-controlled-hardware >>>>>>>>>>>>>>>> Strictly speaking, releases must be verified on hardware >>>> owned >>>>>> and >>>>>>>>>>>>>>> controlled by the committer. That means hardware the >>>> committer >>>>>> has >>>>>>>>>>>>>> physical >>>>>>>>>>>>>>> possession and control of and exclusively full >>>>>>>>>>>>> administrative/superuser >>>>>>>>>>>>>>> access to. That's because only such hardware is qualified >>> to >>>>>> hold a >>>>>>>>>>>>> PGP >>>>>>>>>>>>>>> private key, and the release should be verified on the >>>> machine >>>>>> the >>>>>>>>>>>>>> private >>>>>>>>>>>>>>> key lives on or on a machine as trusted as that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> https://www.apache.org/dev/release-distribution.html#sigs-and-sums >>>>>>>>>>>>>>>> Private keys MUST NOT be stored on any ASF machine. >>>> Likewise, >>>>>>>>>>>>>> signatures >>>>>>>>>>>>>>> for releases MUST NOT be created on ASF machines. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We need to have dedicated physical ARM machines for each >>>>> release >>>>>>>>>>>>> manager, >>>>>>>>>>>>>>> and now it is not feasible. >>>>>>>>>>>>>>> If you provide an unofficial ARM binary release in some >>>>>> repository, >>>>>>>>>>>>>> that's >>>>>>>>>>>>>>> okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Akira >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 12, 2020 at 7:57 PM Brahma Reddy Battula < >>>>>>>>>>>>> bra...@apache.org> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello folks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As currently trunk will support ARM based compilation >> and >>>>> qbt(1) >>>>>>>> is >>>>>>>>>>>>>>>> running >>>>>>>>>>>>>>>> from several months with quite stable, hence planning to >>>>> propose >>>>>>>> ARM >>>>>>>>>>>>>>>> binary >>>>>>>>>>>>>>>> this time. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ( Note : As we'll know voting will be based on the >>> source,so >>>>>> this >>>>>>>>>>>>> will >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> issue.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Proposed Change:* >>>>>>>>>>>>>>>> Currently in downloads we are keeping only x86 >>> binary(2),Can >>>>> we >>>>>>>> keep >>>>>>>>>>>>> ARM >>>>>>>>>>>>>>>> binary also.? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Actions:* >>>>>>>>>>>>>>>> a) *Dedicated* *Machine*: >>>>>>>>>>>>>>>> i) Dedicated ARM machine will be donated which I >>>> confirmed >>>>>>>>>>>>>>>> ii) Or can use jenkins ARM machine itself which is >>>>> currently >>>>>>>>>>>>> used >>>>>>>>>>>>>>>> for ARM >>>>>>>>>>>>>>>> b) *Automate Release:* How about having one release >>> project >>>> in >>>>>>>>>>>>>> jenkins..? >>>>>>>>>>>>>>>> So that future RM's just trigger the jenkin project. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please let me know your thoughts on this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-qbt-linux-ARM-trunk/ >>>>>>>>>>>>>>>> 2.https://hadoop.apache.org/releases.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --Brahma Reddy Battula >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Brahma Reddy Battula >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --Brahma Reddy Battula >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --Brahma Reddy Battula >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: >> yarn-dev-unsubscr...@hadoop.apache.org >>>>>>>>>> For additional commands, e-mail: >>> yarn-dev-h...@hadoop.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --Brahma Reddy Battula >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org >>>>>> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> --Brahma Reddy Battula >>>> >>> >> >> >> -- >> >> >> >> --Brahma Reddy Battula >>
