From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes To: Brian J. Johnson ,devel@edk2.groups.io From: "Sean" X-Originating-IP: 131.107.160.225 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 02 May 2019 12:33:29 -0700 References: <70d2f499-bc28-058a-8675-069beee5835e@hpe.com> In-Reply-To: <70d2f499-bc28-058a-8675-069beee5835e@hpe.com> Message-ID: <31264.1556825609503060272@groups.io> Content-Type: multipart/alternative; boundary="GMUXSCYB9SCKWOmwjfyA" --GMUXSCYB9SCKWOmwjfyA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Laszlo, Except for a very few platforms that are in the current edk2 repo today, e= veryone building products has to deal with this "split repo" reality.=C2=A0= It gets even harder when you account for different business units, differe= nt silicon partners, IBVs, ODMs, open source, closed source, secret project= s, and so on.=C2=A0 The reason I want to bring forth the Project Mu tools t= o Edk2 is that everyone is forced to reinvent this process and tooling ever= y time and it doesn't work very well.=C2=A0 If edk2 continues to ignore the= challenge of most downstream consumers it continues to lead to the results= of today.=C2=A0 Very high cost of integration.=C2=A0 Very low quality of i= ntegrations and very few integrations into products (meaning products don= =E2=80=99t get updates).=C2=A0 The last couple of years has brought signif= icant light to the challenges of updating platform firmware and has shown t= hat the majority of products don't/can't get updates resulting in customers= not being fully protected.=C2=A0=C2=A0 Regarding submodules and boundaries.=C2=A0 I completely agree except that I believe there are numerous boundaries wit= hin a UEFI code base.=C2=A0 As mentioned above one of our goals with splitt= ing the code repositories is to have all code within a repository owned/sup= ported by a single entity.=C2=A0 Another point to splitting is attempting t= o get code with business logic separated from core/common code.=C2=A0 Busin= ess logic often is different across products and if intermixed with core lo= gic it adds significantly to the cost of maintaining the product. =C2=A0Alo= ng your same thinking these different repositories do have different develo= pment models.=C2=A0 Many are closed source and have proprietary change requ= est process.=C2=A0 They all release on different cadences, different depend= encies and very different testing expectations so without a framework that = provides some support this leads to challenging and complicated integration= processes.=C2=A0 =C2=A0 Single repo: It is not possible for most products.=C2=A0 Again when integrating large a= mounts of code from numerous places all with different restrictions it is n= ot practical to have a single bisectable repository with good history track= ing.=C2=A0 Some entities still deliver by zip files with absolutely no src = control history.=C2=A0 Many entities mix open and closed source code and ma= ke hundreds/thousands of in-line changes.=C2=A0 I just don=E2=80=99t see a = path where a product can have 1 git-merged repo and still be able to effici= ently integrate from their upstream sources and track history.=C2=A0 =C2=A0 =C2=A0 =C2=A0 These tools are just a first step down a path to reshaping tianocore edk2 = to be easier to consume (and update) by the ecosystem that depends on Edk2 = for products.=C2=A0 These tools also have solutions for Ci builds, binary d= ependencies, plugins, testing, and other features that edk2 will need for s= ome of the practical next steps.=C2=A0 =C2=A0 Brian, I would really like to hear about the challenges your team faced and issue= s that caused those solutions to be unworkable.=C2=A0=C2=A0Project Mu has a= nd continues to invest a lot in testing capabilities, build automation, and= finding ways to improve quality that scale. =C2=A0 Thanks Sean --GMUXSCYB9SCKWOmwjfyA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Laszlo,

Except for a very few platforms that are in the cu= rrent edk2 repo today, everyone building products has to deal with this = 4;split repo" reality.=C2=A0 It gets even harder when you account for d= ifferent business units, different silicon partners, IBVs, ODMs, open sourc= e, closed source, secret projects, and so on.=C2=A0 The reason I want to br= ing forth the Project Mu tools to Edk2 is that everyone is forced to reinve= nt this process and tooling every time and it doesn't work very well.= =C2=A0 If edk2 continues to ignore the challenge of most downstream consum= ers it continues to lead to the results of today.=C2=A0 Very high cost of i= ntegration.=C2=A0 Very low quality of integrations and very few integration= s into products (meaning products don=E2=80=99t get updates).=C2=A0 The las= t couple of years has brought significant light to the challenges of updati= ng platform firmware and has shown that the majority of products don't/= can't get updates resulting in customers not being fully protected.=C2= =A0=C2=A0

Regarding sub= modules and boundaries.=C2=A0
I completely agree except that I believe there are numerous boundaries wit= hin a UEFI code base.=C2=A0 As mentioned above one of our goals with splitt= ing the code repositories is to have all code within a repository owned/sup= ported by a single entity.=C2=A0 Another point to splitting is attempting t= o get code with business logic separated from core/common code.=C2=A0 Busin= ess logic often is different across products and if intermixed with core lo= gic it adds significantly to the cost of maintaining the product. =C2=A0Alo= ng your same thinking these different repositories do have different develo= pment models.=C2=A0 Many are closed source and have proprietary change requ= est process.=C2=A0 They all release on different cadences, different depend= encies and very different testing expectations so without a framework that = provides some support this leads to challenging and complicated integration= processes.=C2=A0

=C2=A0

Single repo:

It is not possible for most products.=C2=A0 Again when i= ntegrating large amounts of code from numerous places all with different re= strictions it is not practical to have a single bisectable repository with = good history tracking.=C2=A0 Some entities still deliver by zip files with = absolutely no src control history.=C2=A0 Many entities mix open and closed = source code and make hundreds/thousands of in-line changes.=C2=A0 I just do= n=E2=80=99t see a path where a product can have 1 git-merged repo and still= be able to efficiently integrate from their upstream sources and track his= tory.=C2=A0 =C2=A0

=C2=A0

=C2=A0

These tools are just a = first step down a path to reshaping tianocore edk2 to be easier to consume = (and update) by the ecosystem that depends on Edk2 for products.=C2=A0 Thes= e tools also have solutions for Ci builds, binary dependencies, plugins, te= sting, and other features that edk2 will need for some of the practical nex= t steps.=C2=A0

= = =C2=A0

=
Brian,

I would really like to hear about the challenges y= our team faced and issues that caused those solutions to be unworkable.=C2= =A0=C2=A0Project Mu has and continues to invest a lot in testing capabilit= ies, build automation, and finding ways to improve quality that scale.

=C2=A0

Thanks

Sean

--GMUXSCYB9SCKWOmwjfyA--