diff --git a/_includes/site-vars.liquid b/_includes/site-vars.liquid
index 124459ce..b732b837 100644
--- a/_includes/site-vars.liquid
+++ b/_includes/site-vars.liquid
@@ -1,9 +1,6 @@
{% capture prevent_newlines %}
-{% if site.github.url %}
-{% assign baseurl = site.github.url %}
-{% endif %}
-{% assign wiki = "https://github.com/Laurie0131/tianocore/wiki" %}
-{% assign gitbook = "https://www.gitbook.com/@edk2-docs" %}
+{% assign wiki = "https://github.com/tianocore/tianocore.github.io/wiki" %}
+{% assign gitbook = "https://legacy.gitbook.com/@edk2-docs" %}
{% assign edk2files = "http://sourceforge.net/projects/edk2/files" %}
{% assign edk2github = "https://github.com/tianocore/edk2" %}
{% comment %}{% assign laurieadminemail = "laurie0131@users.sourceforge.net" %}{% endcomment %}
diff --git a/bug-triage/index.html b/bug-triage/index.html
new file mode 100644
index 00000000..404d92db
--- /dev/null
+++ b/bug-triage/index.html
@@ -0,0 +1,6 @@
+
+
+
+
+
+
diff --git a/community-meeting/index.html b/community-meeting/index.html
new file mode 100644
index 00000000..275f7c75
--- /dev/null
+++ b/community-meeting/index.html
@@ -0,0 +1,6 @@
+
+
+
+
+
+
diff --git a/community-meetings/index.html b/community-meetings/index.html
new file mode 100644
index 00000000..275f7c75
--- /dev/null
+++ b/community-meetings/index.html
@@ -0,0 +1,6 @@
+
+
+
+
+
+
diff --git a/docs/index.md b/docs/index.md
index 2c7f37e7..ef03c350 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -6,9 +6,7 @@ id: documentation
{% include site-links.md %}
The [TianoCore wiki on github]({{wiki}}){:target="_blank"} is the central repository for project information. Some project information is available as specifications or whitepapers (PDF & GitBook format).
-* [EDK II Specifications]({{wiki}}/EDK-II-Specifications){:target="_blank"}
-* [EDK II User Documentation]({{wiki}}/EDK-II-User-Documentation){:target="_blank"}
-* [EDK II Libraries and Helper files]({{wiki}}/EDK-II-Libraries-and-Helper-files){:target="_blank"}
-* [EDK II White papers]({{wiki}}/EDK-II-white-papers){:target="_blank"}
-* [EDK II Driver Developer Page]({{wiki}}/Driver-Developer){:target="_blank"}
-* [EDK II Documents on GitBook]({{gitbook}}){:target="_blank"}
+
+Please see the wiki page for a complete list of EDK II related documents
+
+* [EDK II Documents wiki page]({{wiki}}/EDK-II-Documents){:target="_blank"}
diff --git a/edk2/index.md b/edk2/index.md
index 2596fb33..6c6c6eaf 100644
--- a/edk2/index.md
+++ b/edk2/index.md
@@ -10,8 +10,7 @@ EDK II is a modern, feature-rich, cross-platform firmware development
environment for the UEFI and PI specifications.
#### License information:
-[BSD](http://www.opensource.org/licenses/bsd-license.php)
-
+[BSD+Patent]((https://opensource.org/licenses/BSDplusPatent)
#### Source repositories:
* edk2 main repository - [https://github.com/tianocore/edk2](https://github.com/tianocore/edk2)
diff --git a/faq.md b/faq.md
index ab18db21..dcf25f9e 100644
--- a/faq.md
+++ b/faq.md
@@ -8,6 +8,6 @@ redirect_from:
TianoCore has accumulated a lot of information over the years. We keep several FAQs on the wiki, organized by topic. The [Member FAQ]({{wiki}}/Member-FAQ){:target="_blank"} is a good starting point. You may also want to review the [EDK II FAQ]({{wiki}}/EDK-II-FAQ){:target="_blank"}, and the [Acronyms and Glossary]({{wiki}}/Acronyms-and-Glossary){:target="_blank"} page.
-If you have a question and cannot find the answer, please try the [EDK II developer email list]({{wiki}}/edk2-devel){:target="_blank"}. You can also search the [e-mail list archive](https://lists.01.org/pipermail/edk2-devel/){:target="_blank"} for questions already asked in email. You can also search the developer [tianocore wiki]({{wiki}}/How-to-Search){:target="_blank"} pages using the github search.
+If you have a question and cannot find the answer, please try the [EDK II developer email list]({{wiki}}/edk2-devel){:target="_blank"}. You can also search the [e-mail list archive](https://lists.01.org/pipermail/edk2-devel/){:target="_blank"} for questions already asked in email. You can also search the developer [TianoCore wiki]({{wiki}}/How-to-Search){:target="_blank"} pages using the github search.
In June 2017, TianoCore added a [Code of Conduct]({{baseurl}}/coc.html) to guide project participation. The code of conduct describes how participants behave in public or in private, whenever the project will be judged by their actions. We expect it to be honored by everyone who represents the project officially or informally, claims affiliation with the project, or participates directly.
diff --git a/files/TianoCoreHackathonRegistrationOSFC.pdf b/files/TianoCoreHackathonRegistrationOSFC.pdf
new file mode 100644
index 00000000..aa74fe1c
Binary files /dev/null and b/files/TianoCoreHackathonRegistrationOSFC.pdf differ
diff --git a/images/GDB_QEMU.JPG b/images/GDB_QEMU.JPG
new file mode 100644
index 00000000..5383e775
Binary files /dev/null and b/images/GDB_QEMU.JPG differ
diff --git a/images/UEFI-Payload.png b/images/UEFI-Payload.png
new file mode 100644
index 00000000..66d51575
Binary files /dev/null and b/images/UEFI-Payload.png differ
diff --git a/index.md b/index.md
index 2010581a..cd88a226 100644
--- a/index.md
+++ b/index.md
@@ -10,7 +10,7 @@ redirect_from:
Welcome to TianoCore, the community supporting an open source implementation of the Unified Extensible Firmware Interface ([UEFI]({{wiki}}/UEFI){:target="_blank"}). [EDK II]({{wiki}}/EDK-II){:target="_blank"} is a modern, feature-rich, cross-platform firmware development environment for the UEFI and UEFI Platform Initialization ([PI]({{wiki}}/PI){:target="_blank"}) specifications. We hope that you’ll review our [wiki]({{wiki}}){:target="_blank"} documentation, use TianoCore for platform firmware, [report any issues]({{wiki}}/Reporting-Issues){:target="_blank"} you find, and contribute to the community.
## Projects and Downloads
-If you want to compile firmware or utilities, we recommend the [Getting Started]({{baseurl}}/getting-started.html) page. This provides an overview of how to download [EDK II from github]({{wiki}}/Getting-Started-with-EDK-II){:target="_blank"}, building a platform or sample application, and [reporting issues in Bugzilla]({{wiki}}/Reporting-Issues){:target="_blank"}.
+If you want to compile firmware or utilities, we recommend the [Getting Started]({{baseurl}}/getting-started.html) page. This provides an overview of how to download [EDK II from github]({{wiki}}/Getting-Started-with-EDK-II){:target="_blank"}, and [reporting issues in Bugzilla]({{wiki}}/Reporting-Issues){:target="_blank"}.
## Background
In June of 2004, Intel announced that it would release the “Foundation Code” of its Extensible Firmware Interface (EFI), a successor to the 16-bit x86 “legacy” PC BIOS, under an open source license. This Foundation Code, developed by Intel as part of a project code named Tiano, was Intel’s “preferred implementation” of EFI. This evolved into EDK, EDK II, and other open source projects under the TianoCore community.
diff --git a/legalese.md b/legalese.md
index 69a02eb2..03965b62 100644
--- a/legalese.md
+++ b/legalese.md
@@ -6,7 +6,8 @@ title: Legal
## Licenses for TianoCore Contributions
-The preferred license for TianoCore is [BSD-2-Clause]({{wiki}}/BSD-License){:target="_blank"}. The [TianoCore contributors agreement](https://raw.githubusercontent.com/tianocore/edk2/master/MdePkg/Contributions.txt){:target="_blank"} describes acceptable licenses for community contributions.
+The preferred license for TianoCore is [BSD+Patent]({{wiki}}/BSD-Plus-Patent-License){:target="_blank"}. When that is not possible, then contributions using
+the following licenses can be accepted:
* BSD (2-clause): [http://opensource.org/licenses/BSD-2-Clause](https://opensource.org/licenses/BSD-2-Clause){:target="_blank"}
* BSD (3-clause): [http://opensource.org/licenses/BSD-3-Clause](http://opensource.org/licenses/BSD-3-Clause){:target="_blank"}
* MIT: [http://opensource.org/licenses/MIT](http://opensource.org/licenses/MIT){:target="_blank"}
diff --git a/minutes/Community-2018-12.html b/minutes/Community-2018-12.html
new file mode 100644
index 00000000..8f4aeeaf
--- /dev/null
+++ b/minutes/Community-2018-12.html
@@ -0,0 +1,237 @@
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+
+
+
+
+
+
+
+
Community Updates
+
We have talks submitted to both FOSDEM and the OCP Summit:
+
+
+
+
+
+
FOSDEM Topics
+
UEFI Capsule Update
+
UEFI Overview - TianoCore & U-Boot
+
+
+
+
OCP Topics
+
TianoCore Roadmap
+
+
+
+
At the start of the community meetings, please feel free to introduce yourself if you'd like your attendance to be recorded in the minutes. This can be done on IRC (OFTC - #edk2) or on the zoom chat feature.
+
+
+
+
Please send feedback to me regarding the dates / times of these meetings. If no comments are heard I will assume that these dates and times are good.
+
+
+
+
January and February's meetings will both be held on *the second week* of the month to accommodate holidays.
+
+
+
+
Opens
+
+ -
+
We would like to setup demos of the current patch systems specific companies are using and record those sessions. Nate can do this for Gerrit and the folks at Microsoft can do the same for Github. John from MS volunteered to do a walk-through of the patch review system as well as CI. Stephano will contact potential demo hosts and setup a time that works for them as well as discuss any concerns with recording the session.
+
+ -
+
There were questions about the release process, specifically the differences between the UDK release and Stable Tag releases.
+
+
+ -
+
For details on Stable Tags, please see the following links:
+
+
+ -
+
A Stable Tag is more frequent than the UDK release. It is a demand based branch rather than a cadence.
+
+ -
+
If a branch is created by the community, is that branch maintained, curated, and allowed to have future versions?
+
+
+ -
+
The community we will discuss how this is addressed.
+
+ -
+
For now, much like the UDK, only critical fixes would be maintained.
+
+ -
+
Please feel free to send additional questions / comments on a new thread.
+
+
+
+ -
+
Build system changes, optimizations of the build system, possibly moving to the make files:
+
+
+
+
+
+
+
+
+
+
+
+
License Change
+
Mark Doran has made it clear that we'll be moving to an Apache 2.0 license. There is an RFC with a detailed proposal here:
+
+
+
+
+
If you are a copyright holder, please look at the RFC, give comments, and if there is a legal process for approval on your end, please start that process. Let us know if there are any concerns from your legal department. There is also a Bugzilla entry for details on code changes:
+
+
+
+
+
There will be a branch that Mike Kinney will create soon so that folks can review the changes to ensure that nothing is incorrect or might cause a build break. There is a script making this change, so the manual review of all these files will be difficult. Community assistance in reviewing those changes is appreciated.
+
+
+
+
Public Design and Bug Scrub Meetings
+
Stephano will send out an RFC to find a frequency and dates/times so that we can setup public design and bug scrub meetings. These are not meetings that everyone needs to join each occurance, however there will be required reviewers identified for specific features and bugs. There will be two meetings held, much like the Community Meeting format, to accommodate different time zones. Current thoughts are that Thursday AM (PST) for EMEA and PM (PST Friday AM Asia) would work, but please comment when the RFC is sent out if you have questions or comments. Making the design and bug scrub meeting agendas clear ahead of time is ideal. Stephano will head up that effort. Also, in each meeting we will collect the next week's possible topics.
+
+
+
+
//COMMENT
+
We need to have a process for the best way to begin a new design idea. We do have a "feature request" in Bugzilla. We also need a way to share documentation in terms of design. Stephano will send out an RFC regarding options for ways of sharing these documents. The design meeting can act as a clarification to possible new feature questions.
+
+
+
+
Patch Review Update
+
GitHub
+
Laszlo has been reviewing GitHub with the help of several folks at Microsoft. Microsoft currently relies on the Web UI of GitHub to archive all the details of their process. Laszlo did find some places where a "force commit" (as one example, there are others) would be visible only for a period of time, but will eventually be lost. There is a concern that the community may not find this level of logging acceptable.
+
+
+
+
Offline use has also been brought up as an issue for those traveling regularly or with intermittent internet connections in their location. We want the TianoCore community to remain open for all to contribute regardless of their location or access to reliable internet.
+
+
+
+
Stephano will send out a RFC, regarding both these issues. Please look at Laszlo's emails (they will be linked) and comment as to how these issues might effect your workflows. Details on any workarounds to these issues that folks have used or have researched are also appreciated.
+
+
+
+
GitLab
+
Philippe Mathieu-Daudé has volunteered to facilitate a review of GitLab and has invited Laszlo to participate. We do not want to overload Laszlo with review tasks so we ask that any community members who have time to work on reviewing this system to please contact Stephano. Ideally this person should be very familiar with our patch review process so that they can give detailed, objective insight into the functionality of the system.
+
+
+
+
Phabricator
+
Laszlo is currently working with Rebecca Cran to evaluate the features of Phabricator and there will be more info on this in upcoming emails.
+
+
+
+
//COMMENT
+
CI will be included in our discussion eventually, however we are focusing on patch review for now.
+
+
+
+
//COMMENT
+
There are future features in both GitLab and Phabricator that will be coming out in the near future. Also, if we could summarize the GitHub issues we could post them to their respective sites as feature requests. In the end, it is important to note which systems have features on the road map and which need feature request submitted. This will be called out in future summary emails / shared documents.
+
+
+
+
Collaboration Software
+
We will be assessing several collaboration software possibilities. We will proceed with testing these options on specific discussion topics, and those discussions will be logged and summarized for the mailing list so as not to lose any information.
+
+
+
+
Stephano will start discussions shortly on GitHub "Team Discussions". This discussions will cover our use of line endings as well as the possible use of standard C types. More of these tests will be forthcoming.
+
+
+
+
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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/minutes/Community-2019-01.html b/minutes/Community-2019-01.html
new file mode 100644
index 00000000..c1a3f209
--- /dev/null
+++ b/minutes/Community-2019-01.html
@@ -0,0 +1,126 @@
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+
+
+
+
+
+
+
+
Community Updates
+ Several conferences are coming up that we will be attending.
+
+
+
+ FOSDEM 2019
+ Stephano will be giving a talk with Alexander Graf (SUSE) on UEFI usage on the UP Squared board and Beagle Bone Black.
+
+
+
+ More info on FOSDEM here:
+
+
+
+
+ Info on the talk here:
+
+
+
+
+ Open Compute Project Global Summit
+
+
+
+
+ No TianoCore talks were accepted for this event, however Stephano will be talking about CHIPSEC.
+
+
+ Other Upcoming Conferences
+
+
+
+
+
+
+
+ Rust
+ Stephano is working with some folks from the Open Source Technology Center at Intel regarding their desire to get Rust ported to EDK2. While there are many proof of concepts out there, the first step for adoption would be to integrate the Rust infrastructure into our build system, and create a simple "hello world" app. The goal would be to provide a modern language with better memory safety for writing modules and drivers. Our hope is that the availability of this language would encourage outside contribution and support from a vibrant and well established open source community.
+
+
+
+ Github Discussions Evaluation, Groups.io, Microsoft Teams
+ During our December community meeting, we talked about trying out "GitHub Discussions" as a basis for communication that might be better than our current mailing list situation. The main issues with the mailing list today are:
+
+
+
+ 1. Attachments are not allowed.
+ 2. Email addresses cannot be "white listed" (If you are not subscribed your emails are simply discarded by the server).
+
+
+
+ In order to save us some time, Stephano reviewed GitHub discussions using 3 GitHub user accounts, and found the following shortcomings:
+
+
+
+ 1. No support for uploading documents, only images
+ 2. No way to archive discussions outside GitHub[1]
+ 3. Any comment can be edited by any member
+ 4. Discussions are not threaded
+
+
+
+ [1] Email notification archiving is possible, but this means we'd have to keep a mailing list log of our conversations. At that point, why not just use email?
+
+
+
+ That last one is particularly difficult to work around. Every comment is added to the bottom of the list. If some small group of developers (out of many) start having a “sub discussion”, their replies will not be separate from the main thread. There’s no way to distinguish and visually “collapse” a sub thread, so one is forced to view the discussion as a whole. It would seem that the "discussion feature" was intended for small, single threaded discussions. This will not work for larger complex system design discussions.
+
+
+
+ Also, the ability to edit comments is perplexing. Any member can edit any comment, and delete any of their comments or edits. No email notifications are provided for these actions, so there may be no document trail for parts of the conversation. This system seems quite inadequate for serious development discussions and is clearly meant for a more "chat" style of communication on smaller teams. Comments and questions regarding "GitHub Discussions" are still welcomed, but Stephano recommends we move forward with trying out different systems with more robust feature sets.
+
+
+
+ It was agreed that we will evaluate Groups.io next to see if that is a better fit for our needs. Stephano will setup accounts as needed and do some preliminary testing. If that goes well he will initiate discussions on "Line Endings" as well as "Use of C Standard Types".
+
+
+
+ Microsoft Teams was also brought up as a possible solution. If Groups.io fails to provide a good platform for us, we will look into Teams. The main barrier to entry there may be the cost. We have found that many of the software options we have been evaluating have this cost barrier to entry. We need to decide if this is truly a "no-go" issue for using software as a community. If TianoCore was an organization that had non-profit status, it might be easier for us to get non-profit discounts on software like this. Stephano will bring this up at the Steward's Meeting next week.
+
+
+
+ Patch Review System Evaluation
+ After evaluating Github, Gitlab, and Phabricator, we will be remaining with the mailing list for now. Github did prove a possible "2nd runner up" (albeit distant), and Stephano / Nate from Intel will be reviewing Gerrit use with a report being sent back to the community sometime next week.
+
+
+
+ Community CI Environment
+ Azure DevOps, Cirrus CI, Jenkins, Avacado
+ We will begin evaluation of possible community test frameworks. This again brings up the question of how we would fund such an effort, and Stephano will bring this up at the Steward's meeting. It is important to remember that our supported environments are Linux, Windows, and macOS. We have compilers that are considered "supported" and those combinations should have proper coverage. Also, we do not want to use multiple CI environments, so the solution we choose should support all use cases. There are several CI options that are "Free for open source" but they limit the size / number of CI agents, with pricing tiers for larger sized builds. The cost of a CI infrastructure will be dependent on the number of patches we need to send through the service, and what kind of response is required. Stephano will work with Philippe on Avacado, the folks at MS will evaluate possible use of Azure DevOps (again, possibly limited by the fact that we are not a non-profit), and volunteers are still required to test Cirrus and Jenkins.
+
+ Public Design / Bug Scrub Meetings
+ We'd like to get public meetings started in February for design overviews and bug scrubs. Stephano will be working with Ray to set these up. The hope is that we will have 1 meeting per month to start for bug scrubs. Design meetings will be dependent on how many design ideas have been submitted. The design meetings could also be used to discuss RFC's from the mailing list.
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/minutes/Community-2019-02.html b/minutes/Community-2019-02.html
new file mode 100644
index 00000000..6717bc8d
--- /dev/null
+++ b/minutes/Community-2019-02.html
@@ -0,0 +1,97 @@
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+
+
+
+
+
+
+
+
Github Pull Requests
We are still considering Github as a possible platform for patch review. There are two issues we'd like to overcome:
comprehensive email notifications or backup/archival functionality
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:
the subject line of the patch
trailing code context of the comment (code that comes AFTER the comment)
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:
+
+
+
+
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:
+
+
+
+
+
+
+
+
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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/minutes/Community-2019-03.html b/minutes/Community-2019-03.html
new file mode 100644
index 00000000..7ee61bf0
--- /dev/null
+++ b/minutes/Community-2019-03.html
@@ -0,0 +1,83 @@
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+
+
+
+
+
+
+
+
License Review
+ The draft of the RFC is out, comments welcome. See details here:
+
+
+
+
+ And V2 is here:
+
+
+
+
+ Please contact Stephano or the stewards directly if you have questions or comments you would not like shared on the list.
+
+
+
+ GitHub Pull Requests
+ Stephano has taken an action item to work with the Kubernetes community to see what trade-offs and benefits they experience using GitHub. Kubernetes is one of the largest open source projects currently using GitHub for patch reviews. It is notable that a git module "request-pull" exists, and the kernel gives directions on how to use these "git style" of pull requests:
+
+
+
+
+
+
+
+ However, it has been noted by the community that GitHub is a much more modern way of doing patch review, hence the continued exploration of this topic. The main blockers are still the inadequate archive of information in email as well as a limited offline workflow. These blockers have been brought up by multiple community members, and Stephano is currently looking for a work around.
+
+
+
+ EDK II Repo Updates
+ We would like to take a cue from Project Mu and improve the structure of the EDK II repository. In the coming weeks, Ray will be leading a lot of the work in terms of retiring packages or moving them to more suitable locations. The stewards have had these conversations over the past few years, and we now have the bandwidth to start moving forward on many of these efforts. We have already introduced edk2-platforms that has platform specific code. Now we need to start moving all platform specific code to that repo. We will also be working on retiring the edk-compatibility package, as well as removing support for EDK1-style capabilities from the BaseTools. There are other work areas around the emulator package regarding running edk2-firmware as an application under Windows, Linux, or macOS, which would let us retire the NT32 package. Adding platform initialization specifications was intended to replace the Intel Framework content. We'd like to see all the platforms move off of those and use the PI defined interfaces so we can remove them. The goal is that in the end the edk2 repository should be platform agnostic, and only keep a few emulation environments to support future integrations. OVMF and the emulator package will still be integral so that any future CI can check for backwards compatibility against those platforms.
+
+
+
+
+
+ Bug Triage
+ Bug triages began in February. See here for details:
+
+
+
+
+ Please join us as we explore bugs and features every 2 weeks.
+
+
+
+ Groups.io
+ Progress is continuing as Laszlo and Stephano have almost finished their review. Things look promising. We should be able to move to Groups.io for our mailing list solving the attachment and white-listing problems. We can also use Groups.io for document storage and design review discussions / doc storage.
+
+
+
+ Design Meetings
+ Design meetings are schedule to begin in March. An announcement will go out sometime in the coming week or so.
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/minutes/Community-2019-04.html b/minutes/Community-2019-04.html
new file mode 100644
index 00000000..c997cb53
--- /dev/null
+++ b/minutes/Community-2019-04.html
@@ -0,0 +1,36 @@
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+License Updates
+
+
+The license change commit is scheduled for April 9th. Any concerns should be raised ASAP.
+
+Mike Kinney is updating the Wiki with the new info.
+
+
+Groups.io Transition
+
+
+Moving to the new mailing list for devel will happen next week. Send any questions / comments to Stephano.
+
+
+We will wait a few weeks before transitioning the "edk2-bugs" mailing list over.
+
+
+Code Columns: 80 vs 120
+
+
+80 is the standards, so we are going to stick with that. Jordan will tweak the documentation to be more clear and update the PatchCheck.py script to reflect this idea.
+
+
+UEFI Plugfest - Seattle
+
+
+The UEFI plugfest will be happening this month. For those attending feel free to ping Stephano. We will most likely be having some TianoCore meetups to discuss the project.
+
+
diff --git a/minutes/Community-2019-05.html b/minutes/Community-2019-05.html
new file mode 100644
index 00000000..0fa5f2bd
--- /dev/null
+++ b/minutes/Community-2019-05.html
@@ -0,0 +1,84 @@
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+
+
+
+
+
+
+
+
Community Updates
-----------------------
April was a busy month for presentations on UEFI, TianoCore, and open source firmware in general. Brian Richardson gave a talk on
HTTPS Boot at the openSUSE Summit in Nashville.
Also, both Brian and Stephano worked a booth at SUSEcon extolling the virtues of HTTPS Boot and explaining how UDP and TFTP are probably not the best idea for network booting.
Mark Doran and Stephano gave a talk about building communities around open source firmware at the UEFI Plugfest in Seattle WA. The event itself happens yearly and only costs $100 so I would highly recommend folks attend if they can. Videos will be posted soon, and the slides from this years talks are already
posted.
There was a firmware track at this years
LinuxFest Northwest. All of the presentations can be found
online. Here are the firmware sessions:
Let There Be Continuous Integration
----------------------------------------
We have begun planning on a CI system, starting small, and building as with a focus on modularity and simplicity. We are starting by building out python scripts, with inspiration from work done my Microsoft, that would allow us to easily spin up a build on a given platform, using a specific toolchain, for a specific target. Once that is completed we will begin to look at different unit/functional tests and how we can best keep them platform agnostic. We'd like our system to be portable, such that folks wishing to use various CI systems (jenkins, travis, teamcity, buildbot, etc) can all take advantage of our tooling. The tests likewise should be portable rather than tied to a specific framework.
+
+
+
+ In effect, we are beginning by considering what our user interface will look like, then considering how that interface can be plugged into existing systems that community members are currently using to build and test internally. Mike Kinney will be leading this effort, and he will reach out to community members who have shown interest and experience with CI systems for advice and perhaps some help. We will also be sending out an RFC to determine what sorts of tests people would like to see initially.
+
+
+
+ LTS Stable Tags: How and When
+ -----------------------------------
+ Since we have moved from UDK branches to stable tags, there has been consideration around supporting these tags long term, and how to best back-port fixes. The main questions are "how" and "when". The when can perhaps be simple, and can exist organically as groups within the community find tags they need to support long-term, and hence do the back-porting that they need.
+
+
+
+ For the "how", we would like to make it easier to determine which patches have been submitted specifically to fix bugs. One way this could be done is with groups.io "hashtags". This would make it easy to filter patches, further filter those patches by bug fixes, and perhaps even specify which stable tag the patch is relating to. By using groups.io "hashtags", we allow both simple web filtering using the groups.io GUI, as well as possible filtering by custom scripts (e.g. in a continuous integration system). An example of these hashtags in an email patch might be:
+
+
+
+ ---
+ [edk2-devel] [PATCH] AwesomePkg/CoolFixPei: fix PEI to be more cool
+
+
+
+ Detailed description of patch such that folks in 6 years will understand what
+ I am changing despite my bewildering code.
+
+
+
+ #patch [#bug 1432] #edk2-stable201811
+ ---
+
+
+
+ The use of hashtags could be extended to flag bug fixes that are #critical or are related to specific #products or #platforms. We will do some testing on this concept to see if it indeed could be a viable solution, however suggestions for other solutions are welcomed.
+
+
+
+
+
+
+ EDK II repo rework
+ ---------------------
+
+ -Quark, MinnowMax / Turbot, and BeagleBoard are being moved out to edk2-platforms
+ -OptionRomPkg, seeing as how it is an example, will be moved out to edk2-platforms
+ -coreboot packages are being replaced by UefiPayloadPkg
+ -Nt32Pkg will be replaced by the EmulatorPkg, which supports running EDK2 under any OS (Linux, macOS, or Windows)
+
+
+
+ MicroPython
+ ---------------
+ Current version of Python available in EDK II are 2.7.2 and 2.7.10 which will all be unsupported at the end of 2019. We don't have a Python 3 port nor any plans to move it forward. Stephano will be sending out an RFC to determine if MicroPython is, as we assume it to be, the best way to move forward. Since we already have a proof of concept port of MicroPython in the MicroPythonTestFramework, we (Stephano) will be drawing up a set of tasks needed to extract the MP port and successfully upstream the parts that make sense.
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/minutes/Community-2019-06.html b/minutes/Community-2019-06.html
new file mode 100644
index 00000000..cb979ca6
--- /dev/null
+++ b/minutes/Community-2019-06.html
@@ -0,0 +1,96 @@
+
+
+
+
+
+ TianoCore Meeting Minutes
+
+
+
+
+
+
+
+ General Updates
+ This month there is a hobbyist / maker event, "Teardown" happening in Portland.
+
+
+
+
+
+
+
+ Teardown is about the practice of hardware prototyping, manufacturing, testing, and disassembling. Stephano will be giving a firmware presentation. Our hope is that we can find some maker boards that would be appropriate to support for our future CI efforts. These boards should be affordable and cover multiple architectures (ARM, x86).
+
+
+
+ Continuous Integration
+ Azure pipelines supports all our needs so that is our first candidate for CI. Azure does not have a caching capability, so each build is essentially from scratch, but they are looking to improve this and code is in the works. We're starting with "cloud" CI services so that we can get a good setup before we worry about buying hardware, spinning up our own infra, keeping things maintained, etc.
+
+
+
+ We recognize that creating a complete CI environment, unit test infrastructure, functional tests, and regression test is a very large task. Instead of working on all of this all at once we are breaking out pieces so as to do this one step at a time. Basic build services are first.
+
+
+
+ Andrew Fish recommended that we find a way to easily evaluate development branches. He suggested a command line tool (probably python) that a maintainer could invoke to generate builds against a branch. However, if we open it up to the world we would crush our CI server, so we need to restrict it to maintainers. This will also force us to think about how we do builds and how we can standardize across platforms, rather than having each platform “roll their own” build process.
+
+
+
+ If you're aware of other CI services, please let us know. (Cirrus CI does not cover all 3 OSs)
+
+
+
+ Hard Freeze / Stable Tag
+ In an effort to avoid policing the maintainers, we will be creating a release meeting before each soft freeze to assure that everyone is aligned. The stewards and maintainers will meet to discuss what is in scope and we can discuss any patches that are currently under review. Our goal is to achieve clear communications and avoid revert commits as much as possible. See the release planning page for upcoming details:
+
+
+
+
+
+
+
+ Also, it has been noted that many contributions have been coming in that do not meet our standards. It is easy to forget what correct contributions should look like. Please review our code contribution guidelines:
+
+
+
+
+
+
+
+ As developers, it’s important to refresh our memory from time to time on these formalities in order to assure our workflow is as seamless as possible.
+
+
+
+ TianoCore Mailling Lists
+ We have added two new mailing lists: discuss & rfc. The goal is to keep the `devel` list as close as possible to pure patch review and developer discussion. Please post your RFCs to the new `rfc` list, and CC the devel list so that those who have not joined the new list will see your discussion. We encourage folks new to the group, or those with questions that may not be of an engineering / development nature, to post to the `discuss` list.
+
+
+
+ We realize that for those of you who simply use MUAs to read the list, this change is not a big win. However, for those using the web interface (Groups.io), keeping these topics separate will make for a cleaner user experience.
+
+
+
+ EDK2 Core Cleanup
+ We continue to move non-essential items out of the edk2 tree and into edk2-platforms as appropriate. June will be the majority of the movement so that things can stabilize for the august release. Some of those are out for discussion (FSP, Silicon). Any comments are welcome, in terms of the general goal: EDK2 is common to all platforms and emulation, as well as QEMU OVMF. The rest of the platform code will live in edk2-platforms. The end goal will be to CI EDK2 only, so as to validate the core. Then the physical platform code can be CI'd separately.
+
+
+
+ Documentation
+ Rebecca is hosting the Doxygen docs from packages on her server, and it is probably better if we use a cloud service to host these, or better yet, our current gitbooks system. However, there is a small issue with the way Doxygen changes folder structures between builds. Since we would be checking this into git (see: gitbook/TianoCore-Docs), it would cause a lot of git history thrashing. Mike has found ways around this, however we want to be sure that searching (particularly across packages) would be possible before we go down this road.
+
+
+
+ Action Items
+ Rebecca: Look into adding BSD as a supported platform. Ping Stephano if documentation changes are needed.
+ Stephano: Update the “about” branch as it is out of date
+ Stephano: Send out an invite to maintainers for the next “soft freeze” release meeting
+
+
+
\ No newline at end of file
diff --git a/monthly-meeting/index.html b/monthly-meeting/index.html
new file mode 100644
index 00000000..1f490845
--- /dev/null
+++ b/monthly-meeting/index.html
@@ -0,0 +1,6 @@
+
+
+
+
+
+
diff --git a/news/_posts/2017-06-30-NewLookWebsite.md b/news/_posts/2017-06-30-NewLookWebsite.md
new file mode 100644
index 00000000..e53662a4
--- /dev/null
+++ b/news/_posts/2017-06-30-NewLookWebsite.md
@@ -0,0 +1,7 @@
+---
+layout: default
+title: Tianocore Website Update
+---
+{% include site-links.md %}
+
+The http://tianocore.org Website has just been updated for a new look and feel. Take a look around and let us know what you think.
diff --git a/news/_posts/2018-01-16-UDK2018Preview.md b/news/_posts/2018-01-16-UDK2018Preview.md
new file mode 100644
index 00000000..5287f08b
--- /dev/null
+++ b/news/_posts/2018-01-16-UDK2018Preview.md
@@ -0,0 +1,7 @@
+---
+layout: default
+title: UDK2018 Preview
+---
+{% include site-links.md %}
+
+Take a look at the features comming for UDK2018 Q1 2018.
diff --git a/news/_posts/2018-04-03-UDK2018Release.md b/news/_posts/2018-04-03-UDK2018Release.md
new file mode 100644
index 00000000..17484be9
--- /dev/null
+++ b/news/_posts/2018-04-03-UDK2018Release.md
@@ -0,0 +1,8 @@
+---
+layout: default
+title: UDK2018 is now released
+---
+{% include site-links.md %}
+
+The latest UEFI Development Kit ( UDK) release UDK2018 is now available.
+ UDK2018 wiki page.
diff --git a/news/_posts/2018-08-08-Quiet-Period.md b/news/_posts/2018-08-08-Quiet-Period.md
new file mode 100644
index 00000000..2f9719c0
--- /dev/null
+++ b/news/_posts/2018-08-08-Quiet-Period.md
@@ -0,0 +1,12 @@
+---
+layout: default
+title: EDK II Stable Tag - Quiet period
+---
+{% include site-links.md %}
+
+EDK II is entering a "quiet period" ahead of the upcoming "stable tag" release, (due Aug 15).
+New features & large changes will have to wait until after the edk2-stable201808 tag.
+
+
+More info:
+https://lists.01.org/pipermail/edk2-devel/2018-August/028210.html
diff --git a/ovmf/index.md b/ovmf/index.md
index 843ad713..97c0cf31 100644
--- a/ovmf/index.md
+++ b/ovmf/index.md
@@ -9,7 +9,7 @@ OVMF is an [EDK II] based project to enable UEFI support for Virtual
Machines. OVMF contains a sample UEFI firmware for [QEMU] and [KVM].
License information:
- [BSD](http://www.opensource.org/licenses/bsd-license.php)
+ [BSD+Patent]((https://opensource.org/licenses/BSDplusPatent)
More information:
[OVMF FAQ]({{wiki}}/OVMF FAQ),
diff --git a/site/index.md b/site/index.md
index 9684422c..dd3ffcc2 100644
--- a/site/index.md
+++ b/site/index.md
@@ -7,7 +7,7 @@ title: TianoCore web site
Our website is open source. Let us know if you have site content or
other website improvements!
-License information: [BSD](http://www.opensource.org/licenses/bsd-license.php){:target="_blank"}
+License information: [BSD+Patent]((https://opensource.org/licenses/BSDplusPatent){:target="_blank"}
Source repository: {:target="_blank"}
diff --git a/training/Learn_n_Development.md b/training/Learn_n_Development.md
index 70e39bfd..a392319d 100644
--- a/training/Learn_n_Development.md
+++ b/training/Learn_n_Development.md
@@ -1,5 +1,6 @@
---
-layout: Default
+layout: acgRedirect
+acgRedirectUrl: https://github.com/tianocore/tianocore.github.io/wiki/UEFI-EDKII-Learning-Dev
title: Learning and Development
---
{% include site-links.md %}
diff --git a/training/index.md b/training/index.md
index 6c54111d..b8b81b04 100644
--- a/training/index.md
+++ b/training/index.md
@@ -1,7 +1,10 @@
---
-layout: default
+layout: acgRedirect
+acgRedirectUrl: https://github.com/tianocore/tianocore.github.io/wiki/Training
title: Training
+redirect_from: "/Training.html"
---
+-
{% include site-links.md %}
@@ -13,5 +16,3 @@ title: Training
* Request for training material: [Material
Request](mailto:{{adminemail}}?Subject=UEFI%20Training%20Material&body=UEFI%20Training%20Material)
-
-Test line
diff --git a/udk/udk2015/index.md b/udk/udk2015/index.md
index 08b02d0d..1a64d188 100644
--- a/udk/udk2015/index.md
+++ b/udk/udk2015/index.md
@@ -1,5 +1,6 @@
---
-layout: default
+layout: acgRedirect
+acgRedirectUrl: https://github.com/tianocore/tianocore.github.io/wiki/UDK2015
title: UDK2015
---