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
