TianoCore Community Meeting Minutes

[Jeremiah Cox <jerecox@microsoft.com>]

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