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.126; helo=mga18.intel.com; envelope-from=stephano.cetola@linux.intel.com; receiver=edk2-devel@lists.01.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 65EB321A00AE6 for ; Tue, 19 Feb 2019 22:24:01 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2019 22:24:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,388,1544515200"; d="scan'208";a="116296068" Received: from scetola-mobl1.amr.corp.intel.com (HELO [10.251.148.167]) ([10.251.148.167]) by orsmga007.jf.intel.com with ESMTP; 19 Feb 2019 22:24:00 -0800 To: "edk2-devel@lists.01.org" From: stephano Message-ID: <6b070757-61b6-c41e-bfd6-aff48a7bf62b@linux.intel.com> Date: Tue, 19 Feb 2019 22:23:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Subject: [edk2-announce] 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: Wed, 20 Feb 2019 06:24:01 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit An HTML version is available here: https://www.tianocore.org/minutes/Community-2019-02.html Github Pull Requests --------------------- We are still considering Github as a possible platform for patch review. There are two issues we'd like to overcome: 1. comprehensive email notifications or backup/archival functionality 2. workflow for users that do not have a consistent internet connection The notification issue degrades our current ability to archive the history of a patch review. Github notifications do not provide: 1. the subject line of the patch 2. trailing code context of comments (code that comes AFTER the comment) 3. the commit message In this way, it is hard to avoid losing the meaning of the pull request conversation if we were to move to a different system some day. The longevity of PR branches is also a concern, and a workaround would need to be found and maintained. We need to be sure that PR branches can be easily archived so that if a Github user deletes their account, even if their PR was rejected, the code would be available. Jeremiah and I are both looking for work around to these issues, hopefully without having to maintain more code. See here for details on Laszlo's thorough Github evaluation: https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html To be clear, these hurtles do not *have to be* overcome. They were brought up by several maintainers and community members. They are simply barriers that we want to discuss fully before committing to a transition. It is impossible to "change our mind" on this transition without some loss of data, so best we be sure before we switch. Working in a community means providing consistent messaging, clear expectations, and the understanding that each member is valuable. Working in the open means moderating, evaluating, and distilling input from community members and companies without bias or prejudice. I take this transition seriously and do not plan to rush it. Gerrit Code Review --------------------- Gerrit code review is viable platform, but Intel's implementation of the 'repo' tool is still working on being open sourced. Also, there would be a lot of work that would go into implementing a proper Gerrit solution. If someone would like to volunteer to carry this out, please feel free to contact me, but I'm going to postpone this for the moment as my schedule is rather full. Groups.io --------------------- Laszlo and I will evaluate Groups.io, however initial impressions is that this will work as a communication platform going forward. We'd like to use this for design discussions and as a replacement for our current mailing list as 01.org does not allow attachments or whistling. Also, Groups.io allows for online search of the list, chats, and uploads which is much easier for some than searching through emails. Assuming this is successful, I will work with 01.org to archive all (if possible) of the edk2-devel mailing list into groups.io for a (mostly) seamless transition. I will see how long 01.org is willing to store archives, and will notify the community of how long that archive will be available. Community Bug Triage --------------------- Community bug triage meetings will occur every two weeks, and we will have 2 meetings to accommodate both sets of timezones. See here for details: https://www.tianocore.org/bug-triage/ I will be working to develop bugzilla reports and researching possible platforms that we could add to a community CI. Maintaining these platforms would be a great way to add to the list of community bugs and encourage open development. Community Design --------------------- We will be starting the community design meetings in March and holding them every 2 weeks. If we find that there are enough submissions we can meet every week. I will hold two meetings, much like the community meetings. Any submission will be discussed in both meeting and notes sent out in the meeting minutes. Discussion can then continue on the mailing list. I will send out an RFC for folks to submit possible topics the day before each meeting. Rust in EDK II Exploration Notes ------------------------------------------ I have been working with the Rust community, as well as members of Intel's Firmware Security teams, to explore the benefits of using Rust in EDK II. For those of you who have never heard of Rust, please take some time to look into it: https://en.wikipedia.org/wiki/Rust_(programming_language) Here is a brief overview of the pros/cons: Benefits of Rust Rust is a modern language with features like counted buffers and strings. It can call C code and be called by C code. It requires no calls to "free", and does so without garbage collection by statically inserting calls to "free" for you. Rust types keep track of which structs own which memory chunks so that developers do not have to keep track of ownership of struct memory. Rust includes a lot of functionality not found in C. These features include Unicode support, an ecosystem library, structural types, and matching (it is very easy to wrap types as a "SUCCESS" or "FAILURE WITH ERROR CODE"). Rust has no NULL pointers as that concept has its own type, which makes for cleaner semantics. It has a robust built in macro system. For example, when you get a compilation error in code calling a macro, the compiler will be able to show you where in the macro the failure occurred. Drawbacks of Rust Rust is a younger language, though there are many examples of where it has been used in production. As such, many features one might take for granted in C still do not exist in Rust, or are newly added. For example, variadic functions (varargs) were just recently added. There are other corner cases of "things you can do in C" that still need to be added. Rust does have a great package management system (called cargo - crates are packages), but in a system like EDK2, we will want to limit those outside dependencies. Sub-command cargo-vendor is a tool where you can pin package versions and update them only as needed. TianoCore in the News --------------------- Here's my presentation from FOSDEM: https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/ I collaborated with Alexander Graf from SUSE. I'll be giving this talk again at LinuxFest Northwest (http://linuxfestnorthwest.org). Thank you all for joining. As always, please feel free to email the list or contact me directly with any questions or comments. Kind Regards, Stephano Cetola TianoCore Community Manager