public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* TianoCore Community Meeting Minutes
@ 2018-10-19 16:09 Jeremiah Cox
  2018-10-22 10:14 ` Laszlo Ersek
  0 siblings, 1 reply; 11+ messages in thread
From: Jeremiah Cox @ 2018-10-19 16:09 UTC (permalink / raw)
  To: stephano; +Cc: edk2-devel@lists.01.org

Finally finding time to respond to an older thread...
>>> 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.
>>
>> Hopefully they said more than that.
>> What does "shouldn't be an issue" mean.
>> Were these users from multiple organisations?
>
>I will ask for more details in the next meeting, but the comments were
>that the API is quite robust and lends itself to readily accessible data.

I'd like to better understand assertions of GitHub "lock in".  GitHub provides a comprehensive REST API that you can easily drive via Python ("pip install PyGithub").
I recall one assertion that GitHub holds PR comments hostage, but it is trivial to dump out all Comments on all PRs in a repo.


   g = Github( <access_token> )
   repo = g.get_repo("chipsec/chipsec")
   pulls = repo.get_pulls(sort='created', base='master')
   for pr in pulls:
      for comment in pr.get_review_comments():
         print(pr.number)
         print(comment.body)
         ...

Can folks help me better understand examples of GitHub "lock in"?  I think it would be trivial to author a daemon that listens for PRs and comments, and forward those to a mailing list, if that is preferred for archival.


>>
>>> Shawn mentioned some benefits to stock Github such as
>>> it is always up to date, it includes APIs to extract data, pull
>>> requests
>>
>> Since we are discussing multiple different development systems, can we
>> try to be a bit more explicit? This is referring to github's web-based
>> branch-based ticketing system, yes?
>
>Yes that's correct.

With respect to web-based, we believe it facilitates convenient, multi-platform access, and GitHub's REST APIs can be leveraged to provide a command-line driven experience.  I believe Sean's point was that GitHub provides a 1-stop shop for code reviews and issue tracking such that there is no need to spend TianoCore resources set up, maintain, and update separate Bugzilla and Gerrit services, VMs, OSs, & machines.  The REST APIs could be used to maintain a mailing list or other mirror.  I am not asserting that GitHub provides the best code review and issue tracker experience, our team finds Azure Dev Ops is superior, but GitHub is sufficient for most use cases while handling the infrastructure so that we can focus on getting things done.

I think it would be helpful to construct a PROs/CONs table for each of the proposed end-to-end solution (source control, code review, gates, CI/CD, issue tracking, testing, ...).  Perhaps this table is on a wiki to enable faster iteration than emails on the DL.


>> I know language drift and all, but
>> <LINK>
>> is what pull request means to at least 3 participants in this conversation.
>
>I think this is an important distinction to make and I'm sure it will
>come up in future discussions. I'll be sure to bring this up.

We think of "Pull Request" as a contribution & review process akin to GitHub, GitLab, or Azure DevOps.  Feedback, responses, automated check-in gates, and signoff can be handled within each PR ticket.  Policies can be assigned, automated tests that must pass, enforcement of community wide rules (# of reviewers, reviewer list, all comments "resolved").  Tests could start as simple as successful build and over time could grow to a more comprehensive set of boot, functional, static analysis, ...
By leveraging a popular hosting provider's built-in workflow we enjoy significant efficiencies.  Its fully documented and known to most.  New capabilities are being added daily.  No TianoCore resources would be required to manage systems, OS patches, network issues, etc and can instead be focused on TianoCore code, building tests, and driving process improvements.


>>
>> It seems somewhat less than ideal to me that all of the github
>> proponents were on the opposite call to me and Laszlo (and Ard). Were
>> any of them Asia-based or could we try to get them on the call with
>> Europe next time? I'm sure me and Laszlo could be somewhat more
>> accommodating than your 7AM, but we're not going to stay up for a 3/4AM
>> meeting about source control.
>
>That's understandable. I'm not sure where Shawn and Nate are located,
>but I believe it is in the US. We could certainly move the AM call a bit
>later if it makes it easier to get more folks from the US on that call.

Agreed, pushing the US/EU call out a couple hours (8 or 9am Pacific) would likely increase Pacific participation.


Thanks,
Jeremiah


^ permalink raw reply	[flat|nested] 11+ messages in thread
* TianoCore Community Meeting Minutes
@ 2018-10-11 17:43 stephano
  2018-10-12 13:27 ` Leif Lindholm
  2018-10-12 20:28 ` Andrew Fish
  0 siblings, 2 replies; 11+ messages in thread
From: stephano @ 2018-10-11 17:43 UTC (permalink / raw)
  To: edk2-devel

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








^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2018-10-22 10:14 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-10-19 16:09 TianoCore Community Meeting Minutes Jeremiah Cox
2018-10-22 10:14 ` Laszlo Ersek
  -- strict thread matches above, loose matches on Subject: below --
2018-10-11 17:43 stephano
2018-10-12 13:27 ` Leif Lindholm
2018-10-12 16:07   ` Laszlo Ersek
2018-10-12 18:06     ` Leif Lindholm
2018-10-12 18:30       ` Kinney, Michael D
2018-10-12 19:44         ` Andrew Fish
2018-10-12 18:50     ` Andrew Fish
2018-10-14 21:15   ` stephano
2018-10-12 20:28 ` Andrew Fish

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox