From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=stephano.cetola@linux.intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A39502114398F for ; Thu, 11 Oct 2018 10:45:40 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 10:45:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,369,1534834800"; d="scan'208";a="87612801" Received: from scetola-mobl1.amr.corp.intel.com (HELO [10.241.241.153]) ([10.241.241.153]) by FMSMGA003.fm.intel.com with ESMTP; 11 Oct 2018 10:43:58 -0700 To: edk2-devel@lists.01.org From: stephano Message-ID: Date: Thu, 11 Oct 2018 10:43:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Subject: TianoCore Community Meeting Minutes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 17:45:40 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Thank you all for a great set of meetings! This is an overview of the topics discussed and the tasks that were assigned. Please feel free to send me any questions or comments. Licensing --------- Licensing was discussed and no questions or comments came up. Please feel free to contact me directly if you would like more info. Community Meetings ------------------ Community meetings will be held regularly. We will plan public bug scrubs and design meetings. Meeting formats will use zoom and be held 2 times per day to accommodate all time zones. Invites will be posted to the mailing list and the wiki. Since the mailing list does not allow attachments, I will work on getting an "add to calendar" link attached to the wiki page. I will send out a poll to see if the community would be interested in a Slack channel. I'm happy to admin it if there is interest. I will also be setting up a specific meeting, probably next month, to discuss general code and commit message standards. Patch Workflow Improvement -------------------------- We would like to find a more modern, user friendly patch workflow that fits (as best as it can) most company's workflow. It is recommended that the community familiarize themselves with some of the options that are out there so that we can pose useful questions / comments at the next meeting. Please be sure to research up-to-date information and not rely on old info. Options and tools discussed included: -Github -Gitlab -Phabricator -Gerrit The was a concern raised over potential lock-in to Github's, specifically in regards to history retention. Several Github users brought up that this shouldn't be an issue. Shawn mentioned some benefits to stock Github such as it is always up to date, it includes APIs to extract data, pull requests lend themselves to simple(r) automation, and it has a much more modern web UI than Gerrit. Several community members including Marcin and Rebecca have used Phabricator and can recommend it. Intel has used Gerrit internally and can recommend its use. No one voiced any issues with Bugzilla and several from the community thought that we should continue to use it. Improvements to the Build Process -------------------------------- We would like to gather a list of concrete specific proposals. Nate mentioned that there will always be some specialized tooling because of the nature of BIOS. Shawn mentioned that we need to keep in mind that making development easier for current developers should be a priority over making the processes easier for newcomers. I will send out emails asking for specific feedback on some of these topics: -Which toolchains are being used, which are validated, and which are known to create reproducible builds. -When toolchains are known to be orphaned, should they be archived or simply removed. -Could we add some kconfig-like tool that allows introspection into what type of builds are available. -How can we better track the code quality of BaseTools and the current build system on the whole. Should we add a "requires documentation change" flag to BZ so that it will be easier to compile a list of required doc changes. Changing to LF instead of CRLF ------------------------------ It was agreed that this is a good idea but that we should create a test repo to verify this change before implementing it. It was noted that this will cause some overhead with tasks like git blame, however the benefits outweigh the costs. Switching to Standard C Types ----------------------------- Both Shawn and Nate mentioned that the current system has been in place for a long time and some people prefer the current setup. I can start an email discussion around this issue specifically if anyone feels strongly that we should be using standard types. Using Git Submodules (like we do with OpenSSL) -------------------- Many in the group liked this idea. I will engage with the communities to gauge their interest in taking patches or helping with our integration of their software. Public CI --------- This subject was not discussed at length but there seems to be quite a bit of community interest. We will discuss this more in the next meeting. Please familiarize yourself with some possible solutions, with a focus on supporting Windows + Linux + Mac. Some possible solutions include: https://azure.microsoft.com/en-us/blog/introducing-azure-devops/ https://cirrus-ci.org/ Mike has tried out Cirrus with some success. Some positive points to Cirrus include: -Build time of ~ 7 Minutes (clone edk2, apt-get all dependent tools, build BaseTools, and build 3 versions of OVMF) -Caching of VM contents so reduce build times of subsequent builds -We could use platforms like OVMF to boot FW and provide test results from tools like MicroPythonTestFramework -Cirrus includes integration with docker Cheers, Stephano Stephano Cetola TianoCore Community Manager stephano.cetola@linux.intel.com