llvm / llvm-iwg Goto Github PK

from meeting on 2021-09-28

• Foundation interested in getting community feedback on code review tools.
  • Goal: evaluate the opportunities/next steps
  • Drafted document to be shared with the community.
  • Please contact Tom in case you want to review the email.
• Round table at dev meeting 2 years ago identified 2 blockers for a migration:
  • Not having a replacement for "Herald rules" from Phabricator (tailored
    email notifications). This would need to be implemented by us.
  • Stacked pull requests are not supported (PR depending on another PR).
    There is a workaround via creating multiple branches and then PRs between
    these branches would. This would require contributors to be able to
    create branches in the repo and leads to lots of open branches.
    Not an ideal solution but it could work.
  • The proposal should probably address these points.
• We probably not only want Pull Requests but more of the features around that.
• Maybe wait until we have a contractor on board to help with investigations
  and implementation.
• The RFC draft is in a Google doc

Hi,

we would like to add a new builder to https://github.com/llvm/llvm-zorg/blob/main/buildbot/osuosl/master/config/builders.py to test building the libLLVM.so. This should be public and outside of Red Hat's control. As far as I understand, I would have to add a worker to the workers.py as well, which will then get picked up by actual hardware. Can the IWG help here?

Thanks

The LLVM Foundation would like to hire someone to help maintain the infrastructure for the project. We would like this working groups to help to define the scope for the role and also to find qualified candidates.

We should document how to request a new repo and what the requirements for that repo are.

From the discussion in #49 the repo must contain these files:

• README.md explaining the contents
• CONTRIBUTING.md (potentially copy from llvm-project)
• LICENSE.TXT (copy from llvm-project)

See discussion on llvm-dev email thread:
https://lists.llvm.org/pipermail/llvm-dev/2021-April/150129.html

Is this a topic we want to work on?
This would simplify #6.

This is part of #22

Document our working mode:

• GitHub repo for documents & meeting minutes, notes taken in markdown
• GitHub issues for planning/coordinating work items
• GitHub Kanban project to track current work items and as agenda for the meetings
• Mailing list for day-to-day non-public conversations
• Zoom video conferences for group discussions

owners: Mishal, Philip, Anton
goals:

• identify 1-2 reasonable companies,
• contact them,
• understand if they can solve our problems,
• understand pricing for our use case,
• understand if this is a feasible solution

subtask: figure out when these meetings are and what the board is interested in

migrated from ChristianKuehnel/iwg-workspace#6

This epic will track the issues around the Mailman to Discourse migration:

• Agree and merge #45 First draft of roadmap and user guide
• #46 Can we preserve the links to the email archive?
• Share draft of the user guide with the community
• Document the new email archive
• #48 Find a solution for cross-posting to multiple categories
• Set up email addresses for creating new topics and redirect them to Discourse
• #94 Define long-term roadmap for mailing list archive
• update all documentation related to mailing lists

Right now the landscape is fragmented by repository and it's not clear where to do the code reviews. So it would be nice if this is documented somewhere.

Migrated from ChristianKuehnel/iwg-workspace#35

We have two topics on the table where we should take a formal decision:

Here's a proposal for taking such decisions:

1. One member of the IWG creates a pull request for the decision and announces it on the [email protected] mailing list.
2. All IWG members review the pull request and comment on the pull request. A 👍 (thumbs up) on the proposal indicates agreement, a 👎 (thumbs down) indicates a disagreement.
3. To accept a proposal we want to see at least t10 👍 and no 👎 .
4. IWG members have two weeks to cast their vote.

Form the IWG meeting on 2021-06-22:

• We should move forward and try to clarify the open points in the userguide.
• We should involve folks from the community in helping resolve these.

goal: investigate alternative solution and help community come to a decision.

This is the long-term perspective to #5

This issue is a collection of all the documentation improvements we discussed:

• Update links to code coverage tools #13
• Document how to find owners of BuildBots ChristianKuehnel/iwg-workspace#37
• Document generation of the website #17
• Document test strategy #18
• Upload tutorials to LLVM website ChristianKuehnel/iwg-workspace#13
• scan through list of BuildBot workers, check if owner information is available #20
• Document which sub-projects are using Phabricator and PullRequests #21
• Document pre-merge checks google/llvm-premerge-checks#275

Some possible solutions:

• Discourse tags?
• Additional Categories?

To get an idea of how cross-posting is used with mailman, I went through and found all threads that were sent to both llvm-dev and cfe-dev in 2020: https://gist.github.com/tstellar/ab2db49f9245a9f99bbefc1c0dbe8244

We should create a proof-of-concept self-hosted runner for Github Actions and enable it for some of the existing CI jobs in the release branch. Once this is working, we should document how to do this, so that community members can easily create their own self-hosted runners.

When creating a proposal for the LLVM board in #32 I noticed that we will need a place to store sensitive information (e.g. pricing).

Requirements:

• not publicly visible
• permissions can be configured per document or folder
• we can at least store textual documents and PDFs
• optional: storing arbitrary files would be nice to have
• ideally something, the LLVM community is familiar with
• It supports some review/collaboration process (e.g. see history and edits, create comments, ...)

Document the test strategy of the LLVM project. Link to other documents where we already have something.

Testing stages I know of:

• local test before submitting a patch
• pre-merge testing on Phabricator
• post-merge testing on buildbots, ...
• release testing (CI and manual)
• downstream testing (TensorFlow, Rust, within companies, linux distros, ...)

For each stage document who does what when.

This would also be the fondation to improve testing. We can then precisely argue which part of the testing process we want to change.

Once we start owning some machines/services, we somehow need to agree on how we manage access to these. #32 will probably be the first case where we need some agreement for that.

We have the following third-party applications approved to access the llvm organization:

• Sourcerer
• Buildkite
• LLVM Buildbot
• LLVM Staging Buildbot
• LLVM Buildbot

https://github.com/organizations/llvm/settings/oauth_application_policy

We should review this and decide what are still needed and create guidelines for granting access.

People frequently refer to emails via their archive links. Also people link emails to other emails via the archive URLs. So it would be really important to find a way to preserve the links after the migration.

It would be great if archive links between emails would be upgraded to links within Discourse. So that clicking on such a link it gets opened in Discourse, not the mailing list archive.

This sentence no verb.

I did not find any documentation on how to generate the html code of the website from the monorepo. This would be useful to have to test changes locally.

Once we have that, add this to the documentation tutorials so people find it:

• https://llvm.org/docs/MarkdownQuickstartTemplate.html
• https://llvm.org/docs/SphinxQuickstartTemplate.html

Once we have the basic documentation in ChristianKuehnel/iwg-workspace#37, scan through the list of workers to make sure that each of them really has an owner that can be contacted. Where that is missing, try to find the owner and ask them to update this information.

Migrated from ChristianKuehnel/iwg-workspace#38

Louis Dionne requested Mac-Hardware for pre-merge testing, details see email conversation on [email protected]

As part of adding an unsupported Bazel configuration, I've set up a Buildkite pipeline that runs the Bazel build on the main branch. Currently it's configured to run every 10 minutes (the shortest cron Buildkite allows), but it would be much nicer to have it instead trigger on pushes to main via webhook. Adding a webhook to a repository requires admin access. I don't think it has any real security implications for a public repository. Is this something someone could help me add?

Note that since this is an unsupported build, I'm not posting statuses on the GitHub commits.

Side note: I wish GitHub had a pubsub model so anyone could subscribe to updates to a public repository. Would also make automatically syncing forks much easier

Topics to be discussed in next meeting:

• Mailman - investigate short term solutions #5
• Mailman - investigate long term solutions #6
• Define scope of the working group ChristianKuehnel/iwg-workspace#41
• Give overview on current situation and roadmap during virtual EuroLLVM dev meeting ChristianKuehnel/iwg-workspace#7

Released to the discussion on using github actions #66 :

• Assuming an attacker could extract the Github runner token, what could they do with that?
• What's the worst that could happen?

We have collected surveys on infrastructure components #10 and development workflows #40 .

The next step is to define the scope of our working group. The outcome should be an initial list of systems/components/features/things we see in scope and want to start looking into. This list will certainly evolve over time.

Migrated from ChristianKuehnel/iwg-workspace#41

and how we can spend our money (and time) wisely.

Migrated from ChristianKuehnel/iwg-workspace#19

This behavior happens with both firefox-86.0.1-1.fc33.x86_64 and chromium-88.0.4324.182-2.fc33.x86_64 .
I cannot access http://green.lab.llvm.org as the browser redirects me to https://green.lab.llvm.org but this site does not support https.
It happens after accessing anything on site https://lab.llvm.org as it sets HSTS for the whole llvm.org domain+subdomains:
lab.llvm.org^partitionKey=%28http%2Cllvm.org%29:HSTS 0 18706 1631821988822,1,1,2
One can delete the line in ~/.mozilla/**/SiteSecurityServiceState.txt but soon it gets added again from accessing any buildbot on lab.llvm.org .
Sure another/better solution would be to fix green.lab.llvm.org to support https.

The Phabricator Github page says:

Effective June 1, 2021: Phabricator is no longer actively maintained.

What should we do about that?

E: Package 'nodejs-dev' has no installation candidate

https://github.com/llvm/llvm-iwg/runs/2146777358?check_suite_focus=true

 Fetched 4272 kB in 3s (1285 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Package libssl1.0-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

Package nodejs-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  libnode-dev

E: Package 'nodejs-dev' has no installation candidate
E: Package 'libssl1.0-dev' has no installation candidate
Error: Process completed with exit code 100.

bases on our discussion during the IWG meeting on 2021-08-17:
We should ask GitHub for more powerful runners to get better build performance.

Looks like the markdown linter in the project (running as GitHub action) has new rules that cause issues with our previous files.

So we need to

1. update the rules for the linter
2. fix the existing files, where it makes sense.

Examples of findings: https://github.com/llvm/llvm-iwg/runs/2259292163

Request from the Foundation: We need to formalise the working group

• elect chair
  • single point of contact for the board
  • point of contact for community
  • organise the working group's efforts
• define list of members
• documentation of responsibilities (e.g. how long do people serve?) as
  guidelines for future members
• how to we agree/vote on things?

Update the website with this information:
https://foundation.llvm.org/docs/infrastructure-wg/

Migrated from ChristianKuehnel/iwg-workspace#22

Is there anything we should do as a working group around the upcoming Dev Meeting in November?

Just saw on Discourse that the Markdown addon "recommonmark" for Sphinx will be deprecated. This is used in generating our llvm.org website.
https://llvm.discourse.group/t/switch-recommonmark-to-myst-parser/3259

The recommended alternative is MyST-Parser. So I guess it would make sense for LLVM to also switch at some point in time...

Do we consider this in scope for our working group?

I suppose this would mean changing the Sphinx config in the repo and upgrading all machines building the documentation.

I (and the MLIR community) would like to add a new repository in the LLVM organization to host an MLIR vscode extension. The extension itself is developed in llvm/llvm-project, but having a unique repository provides an easier integration point into the vscode ecosystem (in terms of publishing to the marketplace and user engagement). There is some amount of prior art for this with clangd, although that repository is not under LLVM and the source code is not developed within the main LLVM monorepo.

Disclaimer: I'm not sure if there is a better way to go about making a proposal like this to the working group, so I apologize in advance if I am posting in the wrong area.

converting @lattner 's email into an issue:

This is super weird and I’m not sure what the issue is, but this page has two links for "[email protected]”. These should be mailto links, but they actually go to the root of the web site when clicked. The markdown looks correct, is this a web site generator issue?

[email protected]

Two other issues I noticed:

1. the “contact us” link on the sidebar is broken - clicking on it is a mailto link but has an extra // in it. I posted this PR to fix it. However I’m a bit concerned that it won’t work due to the above issue.

2. The CI in GitHub is broken on that PR with this error:

Package libssl1.0-dev is not available, but is referred to by another package.
34 This may mean that the package is missing, has been obsoleted, or
35 is only available from another source
36 
37 Package nodejs-dev is not available, but is referred to by another package.
38 This may mean that the package is missing, has been obsoleted, or
39 is only available from another source
40 However the following packages replace it:
41   libnode-dev
42
43 E: Package 'nodejs-dev' has no installation candidate
44 E: Package 'libssl1.0-dev' has no installation candidate
45

-Chris

Requirements:

• No timeout after 40 minutes.
• Everyone should be able to present their screen.
• Everyone should be able to see the raised hands.
• Meeting we can use permanently for all our discussions.

@ChristianKuehnel will talk to Tanya to figure out a way to set this up.

Some ideas:

• Making LLVM developers productive
• Maiking LLVM development fun
• Removing red tape so people can do the work

migrated from ChristianKuehnel/iwg-workspace#11

Proposal

The LLVM Foundation Board of Directors is seeking comment on the current state of Code Review within the LLVM Project and its sub-projects. Phabricator is no longer actively maintained and we would like to move away from a self-hosted solution, so our goal is to determine if GitHub Pull Requests are a good alternative to our current code review tool: Phabricator.

Specifically we are looking for feedback on:

• What features or properties make Github Pull Requests better than Phabricator?
• What features or properties make Phabricator better than GitHub Pull Requests?
• What new workflows or process improvements will be possible with GitHub Pull Requests?
• Which workflows aren’t possible with GitHub Pull Requests?
• Any other information that you think will help the Board of Directors make the best decision.

Where to Direct Feedback

Please provide feedback on this Infrastructure Working Group ticket. This will make it easier to collect and consolidate the responses. At the end of the comment period the Infrastructure Working Group will collect the feedback for further analysis and summarization.

Timeline

The timeline for this RFC will be as follows:

• RFC posted for public review and comment
• 30 days after the date of posting, public comment closes.
• IWG will have 14 days from closure of public comments to review and summarize public comments into a pros and cons list to be present to LLVM Foundation Board
• Foundation Board will have 30 days to make a final decision about using GitHub Pull Requests and then communicate a migration plan to the community.

based on the discussion in #66:
Is there an audit trail for actions on Github triggered via a stolen Github runner token?
Can we somehow figure out what an attacker has done with that token?

We want to have a Kanban board for our working group so we can track the topics we're currently working on, similar to Christian's project: https://github.com/ChristianKuehnel/iwg-workspace/projects/1

At the moment the "projects" feature of GitHub is disabled for all LLVM projects. We probably need to talk to the admins to be able to use that.

Just for tracking the infrastructure effort, the IWG is not involved in this activity.

Current issue tracker: https://bugs.llvm.org/
Original RFC: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143274.html
Request for mapping user names: https://lists.llvm.org/pipermail/llvm-dev/2021-March/149441.html

I guess it would be nice to have a logo for our infrastructure working group. We could use that across our documents and tools.

For details see discussion in ChristianKuehnel/iwg-workspace#12

We need an account to publish on the vscode marketplace. mlir-vscode currently uses a third-party account as does https://github.com/clangd/vscode-clangd Would it make sense to have an 'official' llvm account for publishing the plugins especially for mlir-vscode since it's being published directory from the llvm organization git repository.