public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: stephano <stephano.cetola@linux.intel.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: Jeremiah Cox <jerecox@microsoft.com>,
	Rebecca Cran <rebecca@bluestop.org>
Subject: Community Meeting Minutes #2
Date: Fri, 26 Oct 2018 09:46:57 +0100	[thread overview]
Message-ID: <829e38d9-c679-8b16-f8e7-06e953bc88f4@linux.intel.com> (raw)

Improving the Patch System
--------------------------
We would like to streamline the workflow of our patches making it easier 
for current and future developers to contribute while discouraging 
careless code submissions. We will review several possibilities 
including Fabricator, Github, Gitlab, and Gerrit. We will review these 
solutions by examining case studies as well as community aided research. 
Key goals that we wish to achieve:
1. Offline search of both patches AND comments/conversations
2. Automation of tasks (e.g. lint, merge-fail detection)
3. Automatic notifications (e.g. patch reject, comment added, patch 
pushed to master)

It was made clear that these goals should be implicit in the software, 
not something that we need to script or maintain. Rebecca Cran 
volunteered to help with Fabricator evaluation (thank you), and I will 
be heading up research on the remaining (more volunteers welcome :) ).

Standard C Types
----------------
The only benefit we see to adding Standard C Types might be when we pull 
in modules like LZMA or FDT. We see no reason not to add them, but we 
are hesitant to remove our current type system as it works well and the 
community is comfortable using them. We should have a code standard in 
place to require the use of one or the other, but not both.

Using Submodules
----------------
Assuming our deviations are not large we should follow a pattern of 
using submodules rather than pulling in code directly.

Project Mu
----------
https://microsoft.github.io/mu/

Project Mu is a way of laying out TianoCore into layers, submodules, and 
repos, allowing multiple architectures to share the same core, 
facilitating efficiency and speeding time to market.

https://github.com/Microsoft/mu_basecore

Basecore is the minimum package set that someone would need to build a 
UEFI product.

https://github.com/Microsoft/mu_plus

Mu Plus is an example of optional features, specifically for surface, 
building upon the basecore layer. The Mu Plus repo includes features 
like DSCI (management of remote UEFI settings, targeted at client 
devices). Other groups might add similar layers to enable different 
features.

In the documentation, please see the "MinPlatform Example" and the 
"Surface Example"

To facilitate creating a build environment, they have created a wrapper 
around the current build system.

Liming mentioned that there is currently an area for wrappers in 
BaseTools/Scripts:
https://github.com/tianocore/edk2/tree/master/BaseTools/Scripts

What is the difference between mu_basecore and edk2 master branch?
--addition of large features not yet upstreamed (in progress)
--small changes that need resources to upstream (time constraint)
--rearranging things into different repos to facilitate layering. See: 
https://microsoft.github.io/mu/WhatAndWhy/layout/


Community TODO List
-------------------
Jeremiah: please check to see if the Mu wrapper script is publicly 
available.

Stephano: head up the review of patch systems and write up a report for 
each detailing the pro's & con's, and collect community feedback.


Thank you all for your participation. I will be creating a survey to 
determine the best day & time to meet, and will setup a recurring 
meeting. As always, please feel free to contact me directly with 
comments / questions.

Cheers,
Stephano


Stephano Cetola
TianoCore Community Manager
stephano.cetola@linux.intel.com




             reply	other threads:[~2018-10-26  8:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26  8:46 stephano [this message]
2018-10-26 13:44 ` Community Meeting Minutes #2 stephano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=829e38d9-c679-8b16-f8e7-06e953bc88f4@linux.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox