From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: brian.johnson@hpe.com) Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) by groups.io with SMTP; Tue, 23 Apr 2019 13:37:18 -0700 Received: from pps.filterd (m0150242.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3NKa9HZ006495; Tue, 23 Apr 2019 20:37:17 GMT Received: from g4t3425.houston.hpe.com (g4t3425.houston.hpe.com [15.241.140.78]) by mx0a-002e3701.pphosted.com with ESMTP id 2s27ee456h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Apr 2019 20:37:17 +0000 Received: from g4t3433.houston.hpecorp.net (g4t3433.houston.hpecorp.net [16.208.49.245]) by g4t3425.houston.hpe.com (Postfix) with ESMTP id E85F3BB; Tue, 23 Apr 2019 20:37:16 +0000 (UTC) Received: from [10.33.152.19] (bjj-laptop2.americas.hpqcorp.net [10.33.152.19]) by g4t3433.houston.hpecorp.net (Postfix) with ESMTP id 74F7E46; Tue, 23 Apr 2019 20:37:16 +0000 (UTC) Subject: Re: [edk2-devel] TianoCore Community Design Meeting Minutes To: devel@edk2.groups.io, lersek@redhat.com Cc: ray.ni@intel.com References: <734D49CCEBEEF84792F5B80ED585239D5C0F67BB@SHSMSX104.ccr.corp.intel.com> <865f4141-9a58-ea06-86fb-076ceb7f7376@redhat.com> From: "Brian J. Johnson" Message-ID: <70d2f499-bc28-058a-8675-069beee5835e@hpe.com> Date: Tue, 23 Apr 2019 15:37:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <865f4141-9a58-ea06-86fb-076ceb7f7376@redhat.com> X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-23_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904230145 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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