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 >
