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: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
