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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
