On 4/23/19 1:22 PM, Laszlo Ersek wrote:
On 04/19/19 07:55, Ni, Ray wrote:
Hi everyone,
In the first design meeting, Matthew and Sean from Microsoft presented the Mu
tools.
Below are some notes Mike and I captured from the meeting.
Please reply to this mail for any questions and comments.
Matthew Carlson / Sean Brogan - Microsoft - Project Mu Tools
https://urldefense.proofpoint.com/v2/url?u=https-3A__edk2.groups.io_g_devel_files_Designs_2019_0418_2019-2D04-2D18-2520Microsoft-2520-2D-2520Build-2520Tools-2520-2D-2520Design-2520Review-2520.pdf&d=DwIC-g&c=C5b8zRQO1miGmBeVZ2LFWg&r=joEypYTP_0CJDmGFXzPM2s0mxEmiZkE9j8XY2t0muB0&m=JrIFm-OW7EUMJO_bZcr5RkYsyHrao3YmmSYnCOCMAAg&s=f18bByZUCGrcf2VKMVUAoPNNBz2TKQFLJw1BNphrDc0&e=
I've checked the slides; I'd like to comment on / ask about one
particular topic. The following three items relate to that topic:
(1):
Background
[...]
- Splitting the code: A platform only needs to see the code the platform uses
to build.
(2):
Build a platform through PlatformBuild.py
- Starts with ~1% of platform code
- Dependencies resolving phase pulls additional platform code
* Multiple GIT repos are needed by platform. The dep resolving phase simplifies the
code setup. "setup" phase is isolated and can be skipped or replaced with other
similar tools.
(3): slide 25 / 34:
How do you discover what repos you need?
Platforms define what they need to build and SDE finds it
and "SDE" is explained earlier on slide 22 / 34, "Self Describing
Environment":
Verifies dependencies declared thru ext_deps and updates as needed
While I agree that a platform need not "see" more code than it requires
for being built, the platform is also not *hurt* by seeing more than it
strictly requires.
On the other hand, under a split repos approach, how are
inter-dependencies (between sub-repos) tracked, and navigated? Assume
there is a regression (encountered in platform testing) -- how do you
narrow down the issue to a specific commit of a specific sub-repo? And,
how do you automate said narrowing-down?
In a common git repository / with a common git history, the
inter-dependencies are tracked implicitly, and they aren't hard to
navigate, manually or automatically. Such navigation doesn't need
external tooling; it's all built into git (for example into "git
checkout" and "git bisect").
git supports submodules internally, but that feature exists to mirror
the boundaries that already exist between developer communities. For
example, OpenSSL's developer community and edk2's developer community,
are mostly distinct. Their workflows differ, their release criteria
differ, their testing expectations differ, so it makes sense for edk2 to
consume OpenSSL via a submodule.
But, I don't think the same applies to core modules in e.g. MdeModulePkg
and UefiCpuPkg, vs. *open* firmware platforms. Those development
communities overlap (or should overlap) to a good extent; we shouldn't
fragment them by splitting repos. (Separate subsystem repos and mailing
lists are fine as long as everything is git-merged ultimately into the
central repo.)
Note: I'm not arguing what Project Mu should do for its own sake. I'm
arguing against adopting some Project Mu workflow bits for upstream
edk2, at the level I currently understand those workflow bits. My
understanding of Project Mu could be very lacking. (I missed the design
meeting due to an unresolvable, permanent conflict.) Slide 12/34 says,
"Next Steps: Propose RFC to TianoCore community: Create 3 git
repositories". I hope I can check that out in more detail.
Thanks,
Laszlo
I noticed similar things, and agree with Laszlo's points. My group has
attempted to develop a complex edk2-based project using multiple repos
and some external tooling in the past, and found it completely
unworkable. Perhaps Project Mu's tooling is better than ours was. But
for modules which are developed together by the same group of people,
keeping all the code in a single git repo lets you make the best use of
git, and removes a lot of room for errors when committing code across
multiple modules.
--
Brian J. Johnson
Enterprise X86 Lab
Hewlett Packard Enterprise
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39428): https://edk2.groups.io/g/devel/message/39428
Mute This Topic: https://groups.io/mt/31242794/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
