> 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
