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
