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 > >
