diff --git a/CODE-OF-CONDUCT.md b/CODE-OF-CONDUCT.md new file mode 100644 index 0000000..1d47df4 --- /dev/null +++ b/CODE-OF-CONDUCT.md @@ -0,0 +1,3 @@ +## The Podman Project Community Code of Conduct + +The Podman project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..034eb6a --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,338 @@ +# Contributing to the Podman Container Tools Projects + +We'd love to have you join the community! +Below summarizes the processes that we follow. + +Note the Podman Container Tools organization is a large GitHub organization with many different people working on a lot of different tools and libraries. +The steps listed here do not universally apply to each repository. +Please make sure to read the contributing docs in each repository as they may do things differently. + +This document applies to the following projects: + +- [podman](https://github.com/podman-container-tools/podman) +- [buildah](https://github.com/podman-container-tools/buildah) +- [skopeo](https://github.com/podman-container-tools/skopeo) +- [container-libs](https://github.com/podman-container-tools/container-libs) +- [podman-machine-os](https://github.com/podman-container-tools/podman-machine-os) +- [automation](https://github.com/podman-container-tools/automation) + +This document is not specific to any language; language-specific guidelines are contained in other files. +Rules specific to the Go language can be found [here](CONTRIBUTING_GO.md). +We recommend you read the guidelines of the language your repository is written in after finishing with this file. + +This document is primarily aimed at the above-listed repositories within the Podman Container Tools GitHub organization. +However, most of the things here listed are very generic and apply when contributing to most public projects + +## Topics + +* [LLM ("AI") Policy](#llm-ai-policy) +* [Reporting Issues](#reporting-issues) +* [Submitting Pull Requests](#submitting-pull-requests) + * [Describe your Changes in Commit Messages](#describe-your-changes-in-commit-messages) + * [Sign your PRs](#sign-your-prs) + * [Code review](#code-review) + * [Rebasing](#rebasing) +* [Find bad changes with git bisect](#find-bad-changes-with-git-bisect) + +## LLM ("AI") Policy + +If your contribution is aided by LLMs or other AI tools, please read the [LLM Policy](LLM_POLICY.md). +This project follows this LLM policy, which includes comments, issues, PRs, and any other interactions with the team. + +## Reporting Issues + +Before reporting an issue, check our backlog of Open Issues to see if someone else has already reported it. +If so, feel free to add your scenario, or additional information, to the discussion. +Or simply "subscribe" to it to be notified when it is updated. +Please do not add comments like "+1" or "I have this issue as well" without adding any new information. +Instead, please add a thumbs-up emoji to the original report. + +Note: Older closed issues/PRs are automatically locked. +If you have a similar problem please open a new issue instead of commenting. + +If you find a new issue with the project we'd love to hear about it! +The most important aspect of a bug report is that it includes enough information for us to reproduce it. +Please include as much detail as possible, including all requested fields in the template. +Not having all requested information makes it much harder to find and fix issues. +A reproducer is the best thing you can include. +Reproducers make finding and fixing issues much easier for maintainers. +The easier it is for us to reproduce a bug, the faster it'll be fixed! + +Please don't include any private/sensitive information in your issue! +Security issues should NOT be reported via Github and should instead be reported via the process described [here](SECURITY.md). + +## Submitting Pull Requests + +No Pull Request (PR) is too small! +Typos, additional comments in the code, new test cases, bug fixes, new features, more documentation, ... it's all welcome! + +Our projects follow the normal GitHub PR workflow for contributions. +If you never worked with GitHub and git before you likely first need to understand some basic about them. +The general work you have to do when you contribute the first time is something like this: + - Fork the project on GitHub. + - Clone that fork locally. + - Create a new branch. + - Make your change and commit it. + - Push the branch to your fork. + - Open a PR against the upstream repo. + +You can find some easy tutorial online such as [this one](https://opensource.com/article/19/7/create-pull-request-github) +and check out the official [GitHub docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests) +that contain much more detail. + +All development happens on the `main` branch so all PRs should be submitted against that branch. +Maintainers will take care of backporting if needed. + +While bug fixes can first be identified via an "issue" in Github, that is not required. +It's ok to just open up a PR with the fix, but make sure you include the same information you would have included in an issue - like how to reproduce it. + +PRs for new features should include some background on what use cases the new code is trying to address. +When possible and when it makes sense, try to break-up larger PRs into smaller ones - it's easier to review smaller code changes. +But only if those smaller ones make sense as stand-alone PRs. + +Regardless of the type of PR, all PRs should include: +* Well-documented code changes, both through comments in the code itself and high-quality commit messages. + A commit message should answer *why* a change was made. +* Additional tests. Ideally, they should fail without your code change applied. A test can be a unit test + (see language-specific documentation for details on these) or in a more complex suite often found in the + `test/` or `tests/` directory in each respective repo. Sometimes it may not be possible to add a useful + test (e.g. a race condition that is very hard to trigger), in that case a maintainer can decide to merge + without tests. +* Documentation updates to reflect the changes made in the pull request often found in the `docs/` directory. + +Squash your commits into logical pieces of work that might want to be reviewed separate from the rest of the PRs. +Code changes, test and documentation updates should be part of the same commit as long as they are for the same +feature/bug fix. Dependency updates are best kept in an individual commit. Totally unrelated changes, i.e. +fixing typos in a different code part or adding a completely different feature should go into their own PR. +Often squashing down to just one commit is acceptable since in the end the entire PR will be reviewed anyway. +When in doubt, ask a maintainer how they prefer it. + +When your PR fixes an issue, please note that by including `Fixes: #00000` in the commit description. +More details on this are below, in the "Describe your changes in Commit Messages" section. + +This repository follows a two-ack policy for merges. +PRs will be approved by maintainers listed in the `MAINTAINERS.md` file in the repository. +They will then be merged by a repo owner. Two reviews are required for a pull request to merge. + +### Describe your Changes in Commit Messages + +Describe your problem. +Whether your patch is a one-line bug fix or 5000 lines of a new feature, there must be an underlying problem that motivated you to do this work. +Convince the reviewer that there is a problem worth fixing and that it makes sense for them to read past the first paragraph. + +Describe user-visible impact. +Straight up crashes and lockups are pretty convincing, but not all bugs are that blatant. +Even if the problem was spotted during code review, describe the impact you think it can have on users. +Keep in mind that the majority of users run packages provided by distributions, so include anything that could help route your change downstream. + +Quantify optimizations and trade-offs. +If you claim improvements in performance, memory consumption, stack footprint, or binary size, include +numbers that back them up. +But also describe non-obvious costs. +Optimizations usually aren’t free but trade-offs between CPU, memory, and readability; or, when it comes to heuristics, between different workloads. +Describe the expected downsides of your optimization so that the reviewer can weigh costs against +benefits. + +Once the problem is established, describe what you are actually doing about it in technical detail. +It’s important to describe the change in plain English for the reviewer to verify that the code is behaving as you intend it to. + +Solve only one problem per patch. +If your description starts to get long, that’s a sign that you probably need to split up your patch. + +If the patch fixes a logged bug entry, refer to that bug entry by number or URL. +If the patch follows from a mailing list discussion, give a URL to the mailing list archive. +Please format these lines as `Fixes:` followed by the URL or, for Github bugs, the bug number preceded by a #. +For example: + +``` +Fixes: #00000 +Fixes: https://github.com/podman-container-tools//issues/00000 +``` + +However, try to make your explanation understandable without external resources. +In addition to giving a URL to a mailing list archive or bug, summarize the relevant points of the discussion that led to the patch as submitted. + +If you want to refer to a specific commit, don’t just refer to the SHA-1 ID of the commit. +Please also include the oneline summary of the commit, to make it easier for reviewers to know what it is about. If the commit was merged in Github, referring to a Github PR number is also a good option, as that will retain all discussion from development, and makes including a summary less critical. +Examples: + +``` +Commit f641c2d9384e ("fix bug in rm -fa parallel deletes") [...] +PR #00000 +``` + +When referring to a commit by SHA, you should also be sure to use at least the first twelve characters of the SHA-1 ID. +The Podman repository holds a lot of objects, making collisions with shorter IDs a real possibility. +Bear in mind that, even if there is no collision with your six-character ID now, that condition may change five years from now. + +The following git config settings can be used to add a pretty format for outputting the above style in the git log or git show commands: + +``` +[core] + abbrev = 12 +[pretty] + fixes = Fixes: %h (\"%s\") +``` + +### Sign your PRs + +The sign-off is a line at the end of the explanation for the patch. +Your signature certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch. +The rules are simple: if you can certify the below (from [developercertificate.org](http://developercertificate.org/)): + +``` +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +660 York Street, Suite 102, +San Francisco, CA 94110 USA + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. +``` + +Then you just add a line to every git commit message: + + Signed-off-by: Joe Smith + +Use a real name (sorry, no anonymous contributions). +A real name does not require a legal name, nor a birth name, nor any name that appears on an official ID (e.g. a passport). +Your real name is the name you convey to people in the community for them to use to identify you as you. +The key concern is that your identification is sufficient enough to contact you if an issue were to arise in the future about your contribution. + +If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. + +### Code review + +Once the PR is submitted a reviewer will take a look at it. +Should nobody respond to it within 2 weeks please ping a maintainer. +Sometimes PRs are overlooked or forgotten. + +Keep an eye out for the CI results on the PR. +If all is well then all tasks should succeed. +On some repos the CI tests can take several hours to finish. +If something failed, try to take a look at the logs to see if that seems related to your change or not. +Then try to fix your code or the test depending on what you think is right. +If you are unsure or think it is unrelated, ask a maintainer. +Some tests are flaky and will pass on a re-run. + +After the reviewers and maintainers take a look, they will either write a comment stating `LGTM` (looks good to me) and approve the PR, in which case you do not need to do any further changes, or they write a comment with review feedback that you should address. +Note that most changes require two reviews so only the second reviewer will actually merge the PR. + +If changes were requested, make them locally in your branch and the amend them into the commit from the PR. +You can use `git commit -a --amend` for that. +This will add the current changes to the previous commit. +Please do not push extra commits that say things like "apply code review" or "fix x" where x is a bug introduced in a commit from your PR. +In that case, always squash the change into the right commit to keep the git history clean. +Our projects merge the commits as is and will not squash them on merge to preserve the full original context. + +### Rebasing + +When you create a branch to work on a fix or feature, it no longer will be updated with the latest changes from the upstream `main` branch. +In order to keep your branch up to date you should rebase. + +In order to do so add the upstream repo as remote in git, i.e. for podman-container-tools/podman use: +``` +$ git remote add upstream git@github.com:podman-container-tools/podman.git +``` + +Then fetch the latest changes there with +``` +$ git fetch upstream +``` + +And assuming you are still in your fix/feature branch: +``` +$ git rebase upstream/main +``` + +If the PR is open longer you may have to rebase. +You must rebase when there is a merge conflict. +This means the lines that you changed were also changed after you created your branch. +In this case, Git does not know which change is right. +You will need to manually resolve it. +Check [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line) for more information on how to do this. + +It is recommended to always rebase on a new push to ensure it is testing against the latest code. + +## Find bad changes with git bisect + +git bisect is very powerful command in order to quickly find commits that caused a regression. + +For example, assume you updated Podman and now something that used to work fine is no longer working. +This is called a regression. +If the change was not intentional, it may be hard to identify the cause. +A `git bisect` can help with that. + +First, identify a version that you know worked (the "good version"), and a version that you know does not work (the "bad version"). +Second, ensure you have a simple test for the bug or broken behavior, so you can easily check if a version of the code is broken. +Then, you can run: +``` +$ git bisect start +``` + +Now git will go through the commits between them via binary search to find the first bad commit. +On each commit, you need to compile the binary. +Then, perform your test to see if the commit is broken or not. +Then, use the +``` +$ git bisect good +``` +command if it is working. +If it is not working, use this command instead: +``` +$ git bisect bad +``` + +Compile and test again, repeating these steps until git has only one commit left. +This should be the first bad commit. +If you file an issue, this bisect information is very useful to project reviewers and maintainers as it can quickly lead to the root cause. + +Given this can be a long manual process you can automate the bisect run if you have a good reproducer. +For example, assume there is a regression with `podman run $IMAGE someCommand` where it fails to run and throws an error. +You can automate this after the `git bisect start` command to find the first commit with the problem automatically by using: +``` +$ git bisect run sh -c "make podman && bin/podman run $IMAGE someCommand || exit 1" +``` +This will automatically run the given test command (the `sh -c "..."`) on each commit visited by the binary search. +If the command returns 0, git will automatically mark the commit as good; any other exit code will mark the commit as bad. +The `make podman` command here is required to recompile podman each time we are at a new commit. +This is important as it would otherwise not test the correct binary for the given commit, leading to incorrect results. +Then, after this, run your test of choice. +You can also pass complex scripts or commands. +As long as the exit code is 0 for the good case and > 0 for the bad case, it will work. + +Sometimes `git bisect` is not perfect. +It can fail to find a bad commit. +There can be many reasons for this, but a common one is that the problem is not in the tool you are testing, but rather some external dependency. +Dynamically linked external libraries, external programs called by the tool, or even the kernel could be causing the bug. +In these cases, identifying the cause will be more difficult. + +There is much more useful information in the [git documentation](https://git-scm.com/docs/git-bisect) about this. diff --git a/CONTRIBUTING_GO.md b/CONTRIBUTING_GO.md new file mode 100644 index 0000000..7c1aaa9 --- /dev/null +++ b/CONTRIBUTING_GO.md @@ -0,0 +1,125 @@ +# Contributing to Podman Container Tools Projects: Go Language Guidelines + +This is an appendix to the main [Contributing Guide](CONTRIBUTING.md) and is intended to be read after that document. +It contains guidelines and general rules for contributing to projects under the Podman Container Tools organization that are written in the Go language. +At present, this means the following repositories: + +- [podman](https://github.com/podman-container-tools/podman) +- [buildah](https://github.com/podman-container-tools/buildah) +- [skopeo](https://github.com/podman-container-tools/skopeo) +- [container-libs](https://github.com/podman-container-tools/container-libs) + +## Topics + +* [Unit Tests](#unit-tests) +* [Go Format and lint](#go-format-and-lint) +* [Go Dependency updates](#go-dependency-updates) +* [Testing changes in a dependent repository](#testing-changes-in-a-dependent-repository) +* [git bisect a change in a Go dependency](#git-bisect-a-change-in-a-go-dependency) + +## Unit Tests + +Unit tests for Go code are added in a separate file within the same directory, named `..._test.go` (where the first part of the name is often the name of the file whose code is being tested). +Our Go projects do not require unit tests, but contributors are strongly encouraged to unit test any code that can have a reasonable unit test written. + +### Go Format and lint + +We are using the [`gofumpt`](https://github.com/mvdan/gofumpt) formatter for our go code, you can either use it directly or format via `make fmt`. +For linting we use [`golangci-lint`](https://github.com/golangci/golangci-lint), use `make validate` to run it together with some other basic commit checks. + +## Go Dependency updates + +To automatically keep dependencies up to date we use the [renovate](https://github.com/renovatebot/renovate) bot. +The bot automatically opens new PRs with updates that should be merged by maintainers. + +However sometimes, especially during development, it can be the case that you like to update a dependency. + +To do so you can use the `go get` command, for example to update the storage library to a specific version, use: +``` +$ go get go.podman.io/storage@v1.60.0 +``` + +Or to update it to the latest commit from main use: +``` +$ go get go.podman.io/storage@main +``` + +This command will update the go.mod/go.sum files, in some repos we use [go's vendor mechanism](https://go.dev/ref/mod#vendoring) +so there you must also update the files in the vendor dir. To do so use: +``` +$ make vendor +``` + +If you are working in the [container-libs](https://github.com/podman-container-tools/container-libs) monorepo use: +``` +make vendor +``` +This command syncs the dependency versions across all modules in the repo. + + +Then commit the changes and open a PR. If you want to add other changes it is recommended to keep the +dependency updates in their own commit as this makes reviewing them much easier. + +Note when cutting a new release always make sure we only use tagged version of our own podman-container-tools/... +dependencies to ensure all our tools use the same properly tested library versions. + +## Testing changes in a dependent repository + +Sometimes it is helpful (or a maintainer asks for it) to test your library changes in the final binary, e.g. podman. + +Assume we like to test a container-libs/common PR in Podman so that we can have the full CI tests run there. +First you need to push your container-libs/common changes to your github fork (if not already done). +Now open the podman repository, create a new branch there and then use. +``` +$ go mod edit -replace go.podman.io/common=github.com///common@ +``` +Replace the variable with the correct values, in my case it the reference might be `github.com/Luap99/container-libs/common@myfeature`, where + - account name == `Luap99` + - fork name == `container-libs` + - branch name that I like to test == `myfeature` + +Then just run the vendor command again. +``` +$ make vendor +``` + +Now do any other changes that might be needed after the update and commit the changes then push them +to your Podman fork and open a new Podman PR, marking it as draft to make clear that this is a test +and should not be merged. This will trigger CI to run the tests. If everything passes the +podman-container-tools/container-libs PR did not introduce any regression which is a good. + +Note: You generally do not have to test all your library changes like that. However if your changes +are big or break the API it might be a good idea to do this to avoid regression that need to be +fixed in follow ups or revert. + +## git bisect a change in a go dependency + +If you performed a git bisect and the resulting commit is one that updated a library then most likely +the problem is in that library instead. In such cases it may be needed to find the bad commit from this +repository instead. Thankfully this is not much more difficult than the normal bisect usage. + +Clone the library repository locally (for this example we assume it is github.com/podman-container-tools/container-libs) +which contains the storage library as module in a subdirectory, +I assume it is in a directory next to the podman repo. + +Then in podman run (where you replace the path to the storage repo with your actual one) +``` +$ go mod edit -replace go.podman.io/storage=/path/to/container-libs/storage +$ make vendor +``` + +Now the commit that was already found via the bisect in Podman should show you which storage version +was changed so you can then use them as good and bad version for the bisect in storage. + +So use them in the storage repo for the `git bisect start BAD GOOD` command and then we need a bit +more work for the testing as we have to compile podman in the other repo and perform the check there. + +The automated command can look like this: +``` +$ git bisect run sh -c "cd /path/to/podman && make vendor && make podman && podman run $IMAGE someCommand || exit 1" +``` + +Compared to the normal bisect we basically just have to switch to the podman repo and then update +the vendor directory, as this will copy the local storage repo into that so the build after it +gets the current changes from the bisect commit. Given all works fine the result will point you +to a single commit in storage that caused the podman problem. diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 0000000..7d36cc1 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,247 @@ +# Project Governance + +* [Subprojects](#subprojects) + * [Adding Subprojects](#adding-subprojects) + * [Removing Subprojects](#removing-subprojects) +* [Contributor Ladder](#contributor-ladder) + * [Contributor](#contributor) + * [Reviewer](#reviewer) + * [Maintainer](#maintainer) + * [Core Maintainer](#core-maintainer) + * [Community Manager](#community-manager) + * [Emeritus Maintainer](#emeritus-maintainer) +* [Maintainers File](#maintainers-file) +* [Inactivity](#inactivity) +* [Involuntary Removal](#involuntary-removal-or-demotion) +* [Stepping Down/Emeritus Process](#stepping-downemeritus-process) +* [Updates to this Document](#updates-to-this-document) +* [Contact](#contact) + +# Podman Project + +This document defines the governance of the Podman Project, including its subprojects. It defines the various roles our maintainers fill, how to become a maintainer, and how project-level decisions are made. + +# Subprojects + +The Podman project currently consists of the Podman project (the repository containing this file) and several subprojects: +* [Buildah](https://github.com/podman-container-tools/buildah) +* [Skopeo](https://github.com/podman-container-tools/skopeo/) +* [container-libs](https://github.com/podman-container-tools/container-libs) +* [podman-machine-os](https://github.com/podman-container-tools/podman-machine-os) +* [automation](https://github.com/podman-container-tools/automation) + +## Adding Subprojects + +During a Core Maintainers meeting, any Maintainer or Core Maintainer may recommend projects to become a subproject of Podman Container Tools. These projects should have the following characteristics: +* Are strongly related to Podman Container Tools +* Share the Podman Container Tools mission of delivering a set of tools for building and managing containers on a single node +* Are appropriately licensed and governed or willing to become so +* Are under active development +* Consist of high quality code and designs + +Before submitting an application to the Core Maintainers, the project in consideration must hold a consensus vote among all major contributors to join Podman Container Tools. The Core Maintainers will then review the application, and decide whether or not to accept it. If it is accepted, the Core Maintainers will assign at least one person to assist with the new subproject's integration. The definitive list of subprojects is contained above in the [Subprojects](#subprojects) section above, and the new subproject will be added to that list after its acceptance. The new subproject must map its existing maintainers to the roles defined in the [Contributor Ladder](#contributor-ladder) upon being accepted. Appointments of Community Managers and Core Maintainers from the new subproject are subject to approval by the existing Core Maintainers; other roles may be assigned freely initially, but the Contributor Ladder advancement process must be followed after the project is accepted. + +## Removing Subprojects + +In some cases, subprojects will become inactive or unmaintainable, or wish to separate from Podman Container Tools. Any Core Maintainer may propose the removal of a subproject on these grounds. Additionally, the Maintainers of any subproject may request removal of their subproject by a publicly visible majority vote (for example, via GitHub issue). The Core Maintainers must confirm removals with a majority vote. The subproject will be removed from the list of subprojects in the [Subprojects](#subprojects) section above. + +Subprojects which still have contributors will then be moved to a repository in their own namespace. Projects which have ceased all activity will be kept in the same namespace but archived. + +# Contributor Ladder + +The Podman project has a number of maintainer roles arranged in a ladder. Each role is a rung on the ladder, with different responsibilities and privileges. Community members generally start at the first levels of the "ladder" and advance as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. At all levels, contributors are required to follow the CNCF Code of Conduct (COC). + +Each of the project member roles below is organized into lists of three types of things. + +* "Responsibilities" – functions of a member +* "Requirements" – qualifications of a member +* "Privileges" – entitlements of member + +### Contributor +Description: A Contributor supports the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally. + +* Responsibilities include: + * Follow the CNCF CoC + * Follow the project contributing guide +* Requirements (one or several of the below): + * Report and sometimes resolve issues against any of the project’s repositories + * Occasionally submit PRs against any of the project’s repositories + * Contribute to project documentation, including the manpages, tutorials, and Podman.io + * Attend community meetings when reasonable + * Answer questions from other community members on the mailing list, Slack, Matrix, and other communication channels + * Assist in triaging issues, following the issue triage guide in the respective project repository. + * Assist in reviewing pull requests, including testing patches when applicable + * Test release candidates and provide feedback + * Promote the project in public + * Help run the project infrastructure +* Privileges: + * Invitations to contributor events + * Eligible to become a Reviewer + * For repositories hosted on GitHub, Contributors receive no special privileges by default. Contributors who are active in answering questions and assisting with bug reports upstream may request Triage privileges from the repository's maintainers. + +### Reviewer +Description: A Reviewer has responsibility for the triage of issues and review of pull requests on the Podman project or a subproject, consisting of one or more of the Git repositories that form the project. They are collectively responsible, with other Reviewers, for reviewing changes to the repository or repositories and indicating whether those changes are ready to merge. They have a track record of contribution and review in the project. + +Reviewers have all the rights and responsibilities of a Contributor, plus: + +* Responsibilities include: + * Regular contribution of pull requests to the Podman project or its subprojects + * Triage of GitHub issues on the Podman project or its subprojects + * Regularly fixing GitHub issues on the Podman project or its subprojects + * Following the [reviewing guide](./REVIEWING.md) and [issue triage guide](./TRIAGE.md) + * A sustained high level of pull request reviews on the Podman project or one of its subprojects + * Assisting new Contributors in their interactions with the project + * Helping other contributors become reviewers +* Requirements: + * Has a proven record of good-faith contributions to the project as a Contributor for a period of at least 6 months. The time requirement may be overridden by a supermajority (66%) vote of Maintainers and Core Maintainers. + * Has participated in pull request review and/or issue triage on the project for at least 6 months. The time requirement may be overridden by a supermajority (66%) vote of Maintainers and Core Maintainers. + * Is supportive of new and occasional contributors and helps get useful PRs in shape to merge +* Additional privileges: + * Has rights to approve pull requests in the Podman project or a subproject, marking them as ready for a Maintainer to review and merge + * Can recommend and review other contributors to become Reviewers + * Has permissions to change labels on GitHub to aid in triage + * For repositories hosted on GitHub, Reviewers receive Triage privileges by being added to the `-reviewers` team. + They also will be invited to the `podman-container-tools` GitHub organization as member. + +#### The process of becoming a Reviewer is: +1. The contributor must be sponsored by a Maintainer. That sponsor will open a PR against the appropriate repository, which adds the nominee to the [MAINTAINERS.md](./MAINTAINERS.md) file as a reviewer. +2. The contributor will add a comment to the pull request indicating their willingness to assume the responsibilities of a Reviewer. +3. At least two Maintainers of the repository must concur to merge the PR. + +### Maintainer +Description: Maintainers are established contributors with deep technical knowledge of the Podman project and/or one of its subprojects. Maintainers are granted the authority to merge pull requests, and are expected to participate in making decisions about the strategy and priorities of the project. Maintainers are responsible for code review and merging in a single repository or subproject. It is possible to become Maintainer of additional repositories or subprojects, but each additional repository or project will require a separate application and vote. They are able to participate in all maintainer activities, including Core Maintainer meetings, but do not have a vote at Core Maintainer meetings. + +A Maintainer must meet the responsibilities and requirements of a Reviewer, plus: +* Responsibilities include: + * Sustained high level of reviews of pull requests to the project or subproject, with a goal of one or more a week when averaged across the year. + * Merging pull requests which pass review + * Mentoring new Reviewers + * Participating in CNCF maintainer activities for the projects they are maintainers of + * Assisting Core Maintainers in determining strategy and policy for the project + * Participating in, and leading, community meetings +* Requirements + * Experience as a Reviewer for at least 6 months, or status as an Emeritus Maintainer. The time requirement may be overridden by a supermajority (66%) vote of Maintainers and Core Maintainers. + * Demonstrates a broad knowledge of the project or one or more of its subprojects + * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team + * Mentors contributors, reviewers, and new maintainers + * Collaborates with other Maintainers to work on complex contributions + * Can commit to maintaining a high level of contribution to the project or one of its subprojects +* Additional privileges: + * Represent the project in public as a senior project member + * Represent the project in interactions with the CNCF + * Have a voice, but not a vote, in Core Maintainer decision-making meetings + * For repositories hosted on GitHub, Maintainers receive Maintain privileges by default by being added to the `-maintainers` team and removed from the `-reviewers` teams. + +If a Maintainer needs or wants to work on the CI/CD pipelines and requires elevated access to manage things like secrets or the github runners they +can petition a Core Maintainer to be granted these additional privileges in GitHub. Depending on what kind of access is required they can be given +the 'CI/CD Admin' *Organization* role which enables them access to organization-wide runner and secret configuration, or they can ask for the 'CI/CD Admin' *Repository* role (must be granted per repository) to access the repository level runners or secrets. + +#### Process of becoming a maintainer: +1. A current reviewer must be sponsored by a Maintainer of the repository in question or a Core Maintainer. The Maintainer or Core Maintainer will open a PR against the repository and add the nominee as a Maintainer in the [MAINTAINERS.md](./MAINTAINERS.md) file. The need for a sponsor is removed for Emeritus Maintainers, who may open this pull request themselves. +2. The nominee will add a comment to the PR confirming that they agree to all requirements and responsibilities of becoming a Maintainer. +3. A majority of the current Maintainers of the repository or subproject (including Core Maintainers) must then approve the PR. The need for a majority is removed for Emeritus Maintainers, who require only 2 current Maintainers or Core Maintainers to approve their return. + +### Core Maintainer +Description: As the Podman project is composed of a number of subprojects, most maintainers will not have full knowledge of the full project and all its technical aspects. Those that do are eligible to become Core Maintainers, responsible for decisions affecting the entire project. Core Maintainers may act as a maintainer in all repositories and subprojects of the Podman Project. It is recognized that fulfilling all responsibilities of a maintainer on all project repositories is an excessive time commitment, so Core Maintainers are encouraged to choose one repository to specialize in and to spend most of their time working in that repository. Core Maintainers are encouraged to assist other repositories that require additional reviews as time allows, and should make an effort to review pull requests in other repositories that will affect multiple repositories (especially ones that will effect the repository they have chosen to specialize in). + +* Responsibilities include: + * All responsibilities of a maintainer on a single repository + * Determining strategy and policy for the project +* Requirements + * Experience as a Maintainer for at least 3 months + * Demonstrates a broad knowledge of all components, repositories, and subprojects of the Podman project. + * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team + * Mentors new Maintainers and Core Maintainers + * Able to make decisions and contributions affecting the whole project, including multiple subprojects and repositories + * Can commit to maintaining a high level of contribution to the project as a whole +* Additional privileges: + * Merge privileges on all repositories in the project + * Represent the project in public as a senior project member + * Represent the project in interactions with the CNCF + * Have a vote in Core Maintainer decision-making meetings + * For all repositories hosted on GitHub, Core Maintainers receive Admin privileges by being added as `podman-container-tools` GitHub organization Owner. + * For all repositories hosted on GitHub, Core Maintainers will be added to *all* `-maintainers` teams. Separate from the permissions granted + above, this ensures that Core Maintainers receive pings meant for repository maintainers, as part of their responsibility to assist in code review + and decision making in all repositories. + +#### Process of becoming a Core Maintainer: +1. A current maintainer must be sponsored by Core Maintainer. The Core Maintainer will open a PR against the main Podman repository and add the nominee as a Core Maintainer in the [MAINTAINERS.md](./MAINTAINERS.md) file. +2. The nominee will add a comment to the PR confirming that they agree to all requirements and responsibilities of becoming a Core Maintainer. +3. A majority of the current Core Maintainers must then approve the PR. +4. If, for some reason, all existing members are inactive according to the Inactivity policy below or there are no Core Maintainers due to resignations, a supermajority (66%) vote of maintainers can bypass this process and approve new Core Maintainers directly. + +### Community Manager +Description: Community managers are responsible for the project’s community interactions, including project social media, website maintenance, gathering metrics, managing the new contributor process, ensuring documentation is easy to use and welcoming to new users, and managing the project’s interactions with the CNCF. This is a nontechnical role, and as such does not require technical contribution to the project. + +* Responsibilities include: + * Participating in CNCF maintainer activities + * Arranging, participating in, and leading, community meetings + * Managing the project website and gathering associated metrics + * Managing the project’s social media accounts and mailing lists and gathering associated metrics + * Creating and publishing minutes from Core Maintainer meetings + * Assisting in triage of upstream issues +* Requirements + * Sustained high level of contribution to the community, including attending and engaging in community meetings, contributions to the website, and contributions to documentation, for at least six months + * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team + * Can commit to maintaining a high level of contribution to the project's community, website, and social media presence + * Advocates for the community in Maintainer and Core Maintainer meetings +* Additional privileges: + * Represent the project in public + * Represent the project in interactions with the CNCF + * Have a voice, but not a vote, in Core Maintainer decision-making meetings + * For all repositories hosted on GitHub, Community Managers receive Triage privileges. + +#### Process of becoming a Community Manager: +1. Community Managers must be sponsored by a Core Maintainer. The Core Maintainer will open a PR against the main Podman repository and add the nominee as a Community Manager in the [MAINTAINERS.md](./MAINTAINERS.md) file. +2. The nominee will add a comment to the PR confirming that they agree to all requirements and responsibilities of becoming a Community Manager. +3. A majority of the current Core Maintainers must then approve the PR. + +### Emeritus Maintainer +Emeritus Maintainers are former Maintainers or Core Maintainers whose status has lapsed, either voluntarily or through inactivity. We recognize that these former maintainers still have valuable experience and insights, and maintain Emeritus status as a way of recognizing this. Emeritus Maintainer also offers a fast-tracked path to becoming a Maintainer again, should the contributor wish to return to the project. + +Emeritus Maintainers have no responsibilities or requirements beyond those of an ordinary Contributor. + +#### Process of becoming an Emeritus Maintainer: +1. A current Maintainer or Core Maintainer may voluntarily resign from their position by making a pull request changing their role in the MAINTAINERS file. They may choose to remove themselves entirely or to change their role to Emeritus Maintainer. +2. Maintainers and Core Maintainers removed due to the Inactivity policy below may be moved to Emeritus Status. + +--- + +# Maintainers File + +The definitive source of truth for maintainers of this repository is the local [MAINTAINERS.md](./MAINTAINERS.md) file. The [MAINTAINERS.md](./MAINTAINERS.md) file in the main Podman repository is used for project-spanning roles, including Core Maintainer and Community Manager. + +--- + +# Inactivity + +* Inactivity is measured by one or more of the following: + * Periods of no contribution of code, pull request review, or participation in issue triage for longer than 12 months + * Periods of no communication for longer than 3 months +* Consequences of being inactive include: + * Involuntary removal or demotion + * Being asked to move to Emeritus status + +--- + +# Involuntary Removal or Demotion + +Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, an extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opening up opportunities for new contributors to step in. + +Involuntary removal or demotion of Maintainers and Reviewers is handled through a vote by a majority of the current Maintainers. Core Maintainers may be involuntarily removed by a majority vote of current Core Maintainers or, if all Core Maintainers have stepped down or are inactive according to the inactivity policy, by a supermajority (66%) vote of maintainers. + +--- + +# Stepping Down/Emeritus Process +If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project). + +Maintainers and Reviewers should contact the Maintainers about changing to Emeritus status, or reducing your contributor level. Core Maintainers should contact other Core Maintainers. + +--- + +# Updates to this document +Updates to this Governance document require approval from a supermajority (66%) vote of the Core Maintainers. + +# Contact +* For inquiries, please reach out to: + * [Tom Sweeney, Community Manager](mailto:tsweeney@redhat.com) diff --git a/LLM_POLICY.md b/LLM_POLICY.md new file mode 100644 index 0000000..7fea359 --- /dev/null +++ b/LLM_POLICY.md @@ -0,0 +1,50 @@ +# Podman LLM (AI) Development Policy + +This policy, based on Jellyfin's LLM Policy and licensed under CC-BY-ND-4.0, establishes guidelines for using AI tools in Podman development. + +## No LLM-Generated Direct Communication + +LLM output cannot be used verbatim in: +- Issues, comments, or pull request content +- Forum or chat posts +- Security reports + +All communication must be in your own words and demonstrate understanding. + +**Exceptions:** +- Language translation must be clearly stated +- Maintainer-configured LLM bots may suggest PR changes (suggestions only) + +Violations may result in submission closure or permanent project bans. + +## LLM Code Contributions + +You may use LLMs to assist with code, but you're fully responsible for submissions. + +**Requirements:** +- Follow CONTRIBUTING.md guidelines +- Keep changes concise and focused +- Match existing formatting standards +- Remove unnecessary comments and LLM metadata +- Code must build, run, and pass tests +- Explicitly test modified functionality + +**Understanding and Ownership:** +- Review all generated code +- Explain changes in your own words +- Be able to discuss and justify modifications + +**Handling Review Feedback:** +- Don't paste feedback into LLMs and blindly resubmit +- Respond thoughtfully using your own words +- Make minimal, targeted changes +- Understand required implementations + +**Final Discretion:** +Maintainers may reject oversized, overly complex, or poorly structured PRs after correction attempts, regardless of LLM use. + +## The Golden Rule + +"Do not prompt an LLM vaguely. Do not commit the LLM results unchanged. And do not submit them as-is." + +Using LLMs as tools is acceptable; using them as replacements for understanding and responsibility is not. diff --git a/README.md b/README.md index 90f6ec7..8081c08 100644 --- a/README.md +++ b/README.md @@ -1 +1,46 @@ -Podman Container Tools Community +# Podman Container Tools Community Repository + +This repository serves as the central location for project-wide governance, contribution guidelines, and community documentation for the Podman Container Tools organization. + +## Purpose + +- Provide a dedicated space for administrative and governance documents +- Allow community members to track governance updates without wading through high-volume code issues +- Centralize contribution guidelines and standards across all projects in the organization +- Host meeting minutes and community communications + +## Key Documents + +- **[Governance](GOVERNANCE.md)**: Project governance structure and decision-making processes +- **[Code of Conduct](CODE-OF-CONDUCT.md)**: Community standards and expected behavior +- **[Security Policy](SECURITY.md)**: Security vulnerability reporting and handling procedures +- **[Contributing Guidelines](CONTRIBUTING.md)**: How to contribute to projects in the organization +- **[Go Guidelines](CONTRIBUTING_GO.md)**: Go-specific contribution guidelines +- **[LLM Policy](LLM_POLICY.md)**: Guidelines for using AI tools +- **[Minutes Archive](minutes/)**: Records of community meetings and decisions + +## Related Projects + +This repository provides shared documentation for the following projects in the Podman Container Tools organization: + +- [Podman](https://github.com/podman-container-tools/podman) - Pod manager for OCI containers +- [Buildah](https://github.com/podman-container-tools/buildah) - Tool for building OCI container images +- [Skopeo](https://github.com/podman-container-tools/skopeo) - Tool for working with remote container images +- [Container Libraries](https://github.com/podman-container-tools/container-libs) - Common libraries used across container tools + +Each project maintains its own: +- MAINTAINERS.md file listing project-specific maintainers +- Technical documentation and user guides +- Project-specific issue tracking and development workflows + +## Contributing to This Repository + +Contributions to improve governance documentation, contribution guidelines, or meeting minutes are welcome! + +Please follow the same contribution guidelines outlined in [CONTRIBUTING.md](CONTRIBUTING.md) when submitting changes to this repository. + +## Contact + +For questions or discussions about governance and community matters: +- Open an issue in this repository +- Join the community [channels](https://podman.io/community/#slack-irc-matrix-and-discord). diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..c57a7eb --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,34 @@ +# Security and Disclosure Information Policy for the Podman Container Tools Projects + + * [Reporting a Vulnerability](#Reporting-a-Vulnerability) + * [Security Announcements](#Security-Announcements) + * [Security Vulnerability Response](#Security-Vulnerability-Response) + +## Reporting a Vulnerability + +If you think you've identified a security issue in a Podman Container Tools project, +please DO NOT report the issue publicly via the Github issue tracker, +mailing list, or IRC. Instead, send an email with as many details as +possible to [security@lists.podman.io](mailto:security@lists.podman.io?subject=Security%20Vunerablity%20Report). +This is a private mailing list for the core maintainers. + +Please do **not** create a public issue. + +## Security Announcements + +The [podman@lists.podman.io](mailto:podman@lists.podman.io) email list is used for messages about +Podman security announcements as well as general announcements and +discussions. +You can join the list [here](https://lists.podman.io/admin/lists/podman.lists.podman.io/) +or by sending an email to [podman-join@lists.podman.io](mailto:podman-join@lists.podman.io?subject=subscribe) +with the word "subscribe" in the subject. + +## Security Vulnerability Response + +Each report is acknowledged and analyzed by the core maintainers within 3 working days. + +Any vulnerability information shared with core maintainers stays within a Podman Container Tools project +and will not be disseminated to other projects unless it is necessary to get the issue fixed. + +As the security issue moves from triage, to an identified fix, to release planning, the core +maintainers will keep the reporter updated. diff --git a/minutes/20260424.md b/minutes/20260424.md new file mode 100644 index 0000000..682ab50 --- /dev/null +++ b/minutes/20260424.md @@ -0,0 +1,34 @@ +# Apr 24 2026 + +## Attendees: +* Not captured + +## Key decisions +* We approved subprojects for the new podman github organization. See below for specifics. +* Application for CNCF incubation should be presented to core maintainers *prior* to submission. +* Paul Holzinger will represent core maintainers in any discussions that impact our CI. + + +## Key discussions +* Do all decisions have to be brought to this group? Consensus was "it depends"; some decisions are appropriate +for github while others needs to be discussed. +* We need external meetings for Podman and friends. Unanimous agreement. +* Which sub-projects make sense in the new podman github organization + * container-libs + * podman.io + * buildah.io + * go.podman.io + * machine-os + * podman-py + + The container-selinux project was deferred. + +* Discussion around CNCF incubation and readiness. We agreed that due to the impact of incubation, a +majority (or more) of the core maintainers should be in agreement to move forward. And preferably the +core maintainers should have an opportunity to review it. +* We discussed current state of CI for our repositories. Due to the potential wide-ranging impact of +changes to our CI with no involvement of maintainers, we want a maintainer to be part of those efforts +in terms of design and approval of approaches and methods. +* Core maintainer meeting frequency will now be monthly. +* We need to review the MAINTAINERS.md file with regularity. Brent will review Podman's, Miloslav will +review Skopeo's, and Tom will review Buildahs. diff --git a/minutes/20260626.md b/minutes/20260626.md new file mode 100644 index 0000000..49818ba --- /dev/null +++ b/minutes/20260626.md @@ -0,0 +1,816 @@ +# Podman Core Maintainers Meeting Minutes + +**Date:** June 26, 2026 +**Time:** 14:28 UTC + +--- + +## 1. Meeting Overview & Attendance + +### Present Attendees +* **Matthew Heon** (Red Hat LLC) — Meeting Chair +* **Paul Holzinger** (Red Hat) +* **Brent** (Red Hat LLC) +* **Mohan Boddu** (Red Hat LLC) +* **Giuseppe Scrivano** (Red Hat LLC) +* **Miloslav Trmac** (Red Hat LLC) +* **Nalin Dahyabhai** (Red Hat LLC) +* **Tom Sweeney** (Red Hat LLC) +* **Laura Santamaria** (Red Hat LLC) +* **Ashley Cui** (Red Hat LLC) + +--- + +## 2. Agenda & Discussion Items + +### 2.1. Auditing Permissions Outside of GitHub +* **Context:** Paul Holzinger raised the issue of tracking and auditing administrative permissions for third-party integrations, services, and channels that operate outside of GitHub's access controls. +* **Identified Assets:** * The `podman.io` mailing list (currently hosted on Mailman by the Red Hat Open Source Program Office [OSPO], not CNCF-owned). + * The official project blog. + * CNCF Oracle Cloud infrastructure accounts. + * Read the Docs documentation site (`docs.podman.io`). + * Community communication channels (Matrix and Discord). +* **Key Concerns:** While adding new contributors is straightforward, removing access for inactive or departed members is often forgotten. For example, a former maintainer (Urvashi Mohnani) still retained access to Read the Docs three years after becoming inactive. Additionally, community channels suffer from spam, and not all active maintainers currently have the necessary moderator privileges to handle it promptly. +* **Proposals & Solutions:** * Mohan Boddu suggested looking into an automated daily script tied to a single source of truth for all access controls. + * Miloslav Trmac noted that while OAuth and Single Sign-On (SSO) are ideal, they are often gated behind enterprise tiers which may not be available for open-source project accounts. + * A consensus was reached that all repository maintainers should, at a minimum, be granted moderator permissions on community channels (Matrix/Discord) to clean up spam when primary admins are unavailable. +* **Decisions & Action Items:** + * **Action Item:** Paul Holzinger volunteered to lead the first step, which involves conducting a comprehensive audit of all non-GitHub assets owned by the project, analyzing their authentication systems, and compiling a definitive access list. + * **Decision:** The team agreed to establish a **private GitHub repository** restricted to core maintainers to securely store asset details, documentation, and sensitive audit records. + +### 2.2. CNCF Incubation Application Status +* **Context:** The core maintainers discovered that a CNCF Incubation Application had been filed last week on behalf of Podman. This violated an explicit agreement from the previous meeting stating that no advancement toward incubation would occur without a formal vote and approval from the core maintainers. +* **Issues Identified:** + * The application was filed without a core maintainer vote or prior notification. + * The submission used an outdated/incorrect template, which would trigger an automatic rejection by the CNCF. + * The application contained inaccurate details, falsely listing external projects like `crun` and `Podman Desktop` as official sub-projects. + * The project is not yet structurally prepared for incubation: it lacks a sufficient number of documented adopters and requires a more diversified, non-Red Hat maintainer base (having only recently onboarded its first non-Red Hat maintainer). An official rejection at this stage could negatively impact the project's reputation. +* **Decisions & Action Items:** + * **Decision:** The core maintainers voted unanimously to stop and withdraw the current incubation application until the project is genuinely ready. + * **Action Item:** Matthew Heon will formally contact the CNCF post-meeting to request the immediate closure and withdrawal of the application. + * **Action Item:** To present a unified front, all core maintainers agreed to add public comments to the open GitHub issue indicating that this was a collective maintainer decision. + * **Action Item:** Matthew Heon will post the meeting transcript to the Podman repository to maintain an open public record, and will share the issue link in the `Podman Dev` channel for maintainer responses. + +### 2.3. Proposal for a Shared Documentation Repository (`community`) +* **Context:** Brent followed up on an ongoing discussion regarding the creation of a dedicated repository under the organization to host non-code, project-wide administrative documents (e.g., project governance, code of conduct, security policies, contribution guidelines, and commit formats). +* **Discussion:** Currently, these files live in the main Podman repository, which has inadvertently turned it into a top-level organization repository. Moving these files to a standalone, low-traffic repository allows community members to track governance updates without wading through high-volume code issues. Laura Santamaria noted that this follows a standard industry pattern and strongly recommended naming the repository `community`. +* **Decisions & Action Items:** + * **Decision:** Approved the creation of the repository, officially named **`community`**. + * **Action Item:** Brent will utilize his organization privileges to create the new repository. + * **Action Item:** Mohan Boddu will take ownership of populating the initial content, with Ashley Cui providing additional support as needed. + +### 2.4. Migration of Remaining Repositories to CNCF Organization +* **Context:** The team reviewed the ongoing effort to migrate repositories into the CNCF-governed structure. The migration is roughly 50% complete, with all repositories requiring Continuous Integration (CI) successfully moved. +* **Remaining Repositories:** The outstanding assets include the `podman.io` and `buildah.io` websites, `go.podman.io` (used for Go vanity imports), and the `image_build` repository (which currently has an open pull request requiring review). +* **Discussion on Consolidation:** Mohan Boddu raised a previous discussion about merging the `netavark` and `aardvark-dns` repositories prior to migration. Matthew Heon supported this to minimize administrative overhead. However, Paul Holzinger noted there is no immediate pressure to move them, and Brent explicitly expressed opposition to moving or merging them at this time. The decision on those specific repos was deferred. +* **Decisions & Action Items:** + * **Decision:** The migration will proceed for the core remaining repos that meet the established criteria (fundamentally related to Podman, matching licensing/governance rules, and approved by maintainers). + * **Action Item:** Matthew Heon will continue to lead the migration process for `podman.io`, `buildah.io`, `go.podman.io`, and `image_build`, including coordinating the necessary maintainer votes. + +### 2.5. Quarterly Audit of Maintainer Files +* **Context:** The quarterly schedule for auditing maintainer files has arrived. The goal is to review active contributions and transition inactive maintainers to more appropriate or emeritus roles. +* **Decisions & Action Items:** + * **Decision:** Matthew Heon was designated to review all project repositories and draft a proposal identifying inactive maintainers for removal or role adjustments. + +--- + +## 3. Summary of Action Items + +| Owner | Action Item | +|:---------------------|:----------------------------------------------------------------------------------------------------------| +| **Paul Holzinger** | Conduct a comprehensive audit of all non-GitHub project assets. | +| **Matthew Heon** | Contact the CNCF to officially withdraw the unauthorized incubation application. | +| **Core Maintainers** | Post public comments on the open incubation GitHub issue to confirm the joint decision. | +| **Matthew Heon** | Upload the meeting transcript to the repository and share the issue link in `Podman Dev`. | +| **Brent** | Create the new `community` GitHub repository under organization settings. | +| **Mohan Boddu** | Populate the newly created `community` repository with governance and policy files. | +| **Ashley Cui** | Assist Mohan Boddu with population and review of the `community` repository. | +| **Matthew Heon** | Drive the migration and maintainer votes for `podman.io`, `buildah.io`, `go.podman.io`, and `image_build`. | +| **Matthew Heon** | Review all maintainer files across project repos and propose updates for inactive members. | + +--- +*These minutes were generated by AI. A full transcript of the meeting is below.* + +## 4. Transcript + +Unrelated chatter at beginning of meeting has been trimmed for brevity + +25 +00:04:00.360 --> 00:04:07.990 +Matthew Heon (Red Hat LLC): Okay, sorry about that. I had to re-invite Brent. Hopefully he will join in the next couple minutes. + +26 +00:04:08.360 --> 00:04:10.460 +Matthew Heon (Red Hat LLC): In the meantime, I think we can… + +27 +00:04:10.660 --> 00:04:16.930 +Matthew Heon (Red Hat LLC): Probably get started with some of the, easier to deal with, matters on the agenda. + +28 +00:04:17.250 --> 00:04:26.900 +Matthew Heon (Red Hat LLC): So, first thing I would like to go over is a suggestion from Paul. How do we audit permissions outside of GitHub? + +29 +00:04:26.900 --> 00:04:39.410 +Matthew Heon (Red Hat LLC): Including who has access to and control over the Podman mailing list, access to things like our blog, yeah. So, Paul, you wanna leave this one off? + +30 +00:04:42.830 --> 00:04:48.260 +Paul Holzinger: Yeah, I don't… I don't have a proposal or anything, I think it's just something to be aware of, yes. + +31 +00:04:48.430 --> 00:04:50.310 +Paul Holzinger: I don't know how many other… + +32 +00:04:50.990 --> 00:04:57.590 +Paul Holzinger: third-party integrations or tools where there's different authentication and… + +33 +00:04:58.200 --> 00:05:05.360 +Paul Holzinger: You know, we can, update our maintainer files, I think we can reasonably be well audit GitHub permissions. + +34 +00:05:05.870 --> 00:05:11.080 +Paul Holzinger: But… yeah, like, I don't know, everything else, the… + +35 +00:05:11.300 --> 00:05:16.289 +Paul Holzinger: Podman.io mailing list has different logins, with different people having access. + +36 +00:05:17.090 --> 00:05:23.920 +Paul Holzinger: The block is different, the… we got a CNCF Oracle Cloud account, which… + +37 +00:05:24.210 --> 00:05:28.109 +Paul Holzinger: I guess it's also just personal accounts and some email you have. + +38 +00:05:28.520 --> 00:05:29.830 +Paul Holzinger: for, like… + +39 +00:05:30.400 --> 00:05:42.180 +Paul Holzinger: I mean, adding people that need access is always easy. It's remembering to kick people out when they no longer should have access. That's more the concern, I guess. + +40 +00:05:49.610 --> 00:05:53.480 +Mohan Boddu (Red Hat LLC): Is there a way that we can maintain a single source of truth? + +41 +00:05:53.820 --> 00:06:01.860 +Mohan Boddu (Red Hat LLC): But… Kind of, like, runs every day to update all the access controls. + +42 +00:06:05.020 --> 00:06:16.279 +Miloslav Trmac (Red Hat LLC): I think the traditional solution is to use OAuth and single sign-on everywhere, but then accepting OAuth is an enterprise feature that might not be available to us. + +43 +00:06:23.660 --> 00:06:30.760 +Paul Holzinger: Yeah, I mean, the single sign-on would definitely be lovely, but the next problem would be even convincing the various + +44 +00:06:31.720 --> 00:06:32.390 +Paul Holzinger: Holy crap. + +45 +00:06:32.390 --> 00:06:34.890 +Miloslav Trmac (Red Hat LLC): Who lost that in the first place, right? + +46 +00:06:36.710 --> 00:06:47.300 +Paul Holzinger: Yeah, I mean, so Podman I.O. mailing list, that's another thing, is, as far as I know, this is still hosted by the OSPO, by the Red Hat OSPO, this is not something CNCF. + +47 +00:06:47.710 --> 00:06:48.760 +Paul Holzinger: owned. + +48 +00:06:49.380 --> 00:06:57.280 +Paul Holzinger: And that's just, what is this, mailman tree, or whatever that's running? I don't know. + +49 +00:06:58.280 --> 00:06:59.400 +Paul Holzinger: And… + +50 +00:06:59.960 --> 00:07:06.510 +Paul Holzinger: I don't know, there's probably something that could be done for something like that, but yeah, there's so many random… like, I'm… + +51 +00:07:07.150 --> 00:07:24.369 +Paul Holzinger: We can definitely try to automate some stuff, if they have APIs for, like, the off stuff, but yeah, it's just, like, a general problem of, like, anything. Like, if you think further, there's a read the docs page for docs.potment.io. How do we make sure that people have access to that? + +52 +00:07:24.610 --> 00:07:34.410 +Paul Holzinger: I have, Brent has, and when I had to make a change this week, I saw, like, for example, we have Wagashi there, who had the exercise, which… + +53 +00:07:34.760 --> 00:07:42.899 +Paul Holzinger: She had, because she was a maintainer, but, like, 3 years ago, not anymore, so, like, how do we, you know, remember? + +54 +00:07:44.410 --> 00:07:50.030 +Paul Holzinger: or even start knowing where we have all these tokens, I think that's the first thing, like, I don't know. + +55 +00:07:50.390 --> 00:07:57.859 +Paul Holzinger: There's probably a lot of things that we don't remember, even, that people might… eat stuff from. + +56 +00:07:59.740 --> 00:08:06.529 +Matthew Heon (Red Hat LLC): I mean, Dan is still… basically has access to everything, I think, right? So we could probably… + +57 +00:08:06.770 --> 00:08:13.499 +Matthew Heon (Red Hat LLC): I don't… he's still technically a builder maintainer, but he's not active enough to have access to most of this stuff anymore, so we can also… + +58 +00:08:13.930 --> 00:08:28.319 +Matthew Heon (Red Hat LLC): Yeah, I think an audit… I mean, would the first step here just be an audit of the stuff that we actually have? I don't think we have a conclusive list anywhere of all the stuff that we actually maintain for the project. + +59 +00:08:30.550 --> 00:08:35.710 +Paul Holzinger: Yeah, I think that's the first thing, just figuring out What? + +60 +00:08:35.900 --> 00:08:39.890 +Paul Holzinger: Kind of things we own as a collective project, and… + +61 +00:08:40.289 --> 00:08:48.929 +Paul Holzinger: then checking how the authentication systems work, I guess, and who has access. Like, another thing is, that I haven't mentioned yet. + +62 +00:08:49.200 --> 00:08:54.680 +Paul Holzinger: our community channels, like, we have a Matrix channel, there's a Discord server. + +63 +00:08:54.850 --> 00:08:59.080 +Paul Holzinger: But, you know, like, there's a lot of things, basically. + +64 +00:09:01.370 --> 00:09:10.609 +Paul Holzinger: And, for example, I think everybody should have at least, like, moderator access to these channels. Like, if somebody is doing stupid stuff there, they should be able to then… + +65 +00:09:10.910 --> 00:09:13.150 +Paul Holzinger: people, right? Like, I mean, we get a lot of + +66 +00:09:14.010 --> 00:09:20.749 +Paul Holzinger: Yeah, the usual spam, what you get in these channels, like, it would be nice if everybody has the ability to remove those, if, + +67 +00:09:20.940 --> 00:09:29.949 +Paul Holzinger: people with access are not around, because the current list is definitely smaller than the list of all the possible maintainers in all repos, I think. + +68 +00:09:36.300 --> 00:09:53.699 +Matthew Heon (Red Hat LLC): So, it does sound like our first step is, just do an audit of things that we own, so we can produce a list of that, and then from there, we can extend auditing permissions on everything, and then from there, we can extend even further to… maybe there's a way to have a single source of truth. + +69 +00:09:53.900 --> 00:10:03.089 +Matthew Heon (Red Hat LLC): Does anyone want to own this work, at least the first step of figuring out the stuff that we are… that is associated with the project, and ideally making a list of it? + +70 +00:10:05.400 --> 00:10:06.899 +Paul Holzinger: I, I can take that. + +71 +00:10:07.790 --> 00:10:09.489 +Matthew Heon (Red Hat LLC): Okay. Thank you, Paul. + +72 +00:10:11.580 --> 00:10:13.510 +Matthew Heon (Red Hat LLC): All right. + +73 +00:10:13.510 --> 00:10:16.379 +Miloslav Trmac (Red Hat LLC): Yes, we can keep the address reasonably private. + +74 +00:10:19.800 --> 00:10:24.229 +Miloslav Trmac (Red Hat LLC): Probably not worth worrying right now, but eventually there might be weak links there. + +75 +00:10:26.790 --> 00:10:28.560 +Matthew Heon (Red Hat LLC): I mean, we have… + +76 +00:10:29.400 --> 00:10:41.139 +Matthew Heon (Red Hat LLC): Topic 2 was going to be, creating a GitHub repository for all of our public content, that being stuff like the governance and, maintainer lists. + +77 +00:10:41.390 --> 00:10:57.490 +Matthew Heon (Red Hat LLC): But that would not be a private place, that would be completely public. I don't know. Maybe we can ask the CNCF if we can have an internal repo that we can… or a private repo, rather, on GitHub, that we can access control to just maintainers. + +78 +00:11:01.000 --> 00:11:09.859 +Paul Holzinger: like, creating private repos, that's possible, like, I mean, you are owners, you, like, I don't think there's any restriction, + +79 +00:11:11.360 --> 00:11:14.400 +Paul Holzinger: from the, like, GNCF org thing. + +80 +00:11:15.310 --> 00:11:18.840 +Matthew Heon (Red Hat LLC): Okay Alright, in that case, yeah. + +81 +00:11:19.060 --> 00:11:23.369 +Matthew Heon (Red Hat LLC): I would vote that we just make a private repo, and we store all details there. + +82 +00:11:26.780 --> 00:11:32.510 +Matthew Heon (Red Hat LLC): All right, anything more on this? Otherwise, we have a fairly full agenda, so I'd like to keep it moving. + +83 +00:11:34.900 --> 00:11:45.959 +Matthew Heon (Red Hat LLC): Okay, with Brent actually available right now, let's go on to what was supposed to be our first topic, that being, the incubation application. + +84 +00:11:46.280 --> 00:12:01.819 +Matthew Heon (Red Hat LLC): So, last time we met, we agreed that there would be no move to incubation without having a vote of the core maintainers. However, we became aware last week that an incubation application was filed. + +85 +00:12:01.960 --> 00:12:17.570 +Matthew Heon (Red Hat LLC): I don't think that we are prepared right now for this. We don't have enough adopters for the project listed. We don't have enough maintainers, who are not Red Hat. Like, we've only just acquired our first non-Red Hat maintainer. + +86 +00:12:17.980 --> 00:12:34.559 +Matthew Heon (Red Hat LLC): This application was a surprise to, I think, everyone in this room. There was no core maintainer vote, no notification even to the core maintainers. It was filed using the wrong template, and because of that, the CNCF will reject it if it keeps going. + +87 +00:12:34.800 --> 00:12:38.669 +Matthew Heon (Red Hat LLC): And I think that that would have potential negative implications for the project. + +88 +00:12:39.230 --> 00:12:46.329 +Matthew Heon (Red Hat LLC): So, based on all of these things, I move that, we have a core maintainer vote to + +89 +00:12:46.450 --> 00:12:52.859 +Matthew Heon (Red Hat LLC): Stop this application and basically formally say we are withdrawing until we feel like we are actually ready. + +90 +00:12:58.320 --> 00:13:01.010 +Matthew Heon (Red Hat LLC): Anyone object to this? + +91 +00:13:03.580 --> 00:13:08.580 +Paul Holzinger: Yeah, I… I posted the link for those who haven't seen it yet. The… + +92 +00:13:08.840 --> 00:13:14.179 +Paul Holzinger: My biggest problem is, yeah, like you said, there was no vote on it, no communication, and… + +93 +00:13:14.460 --> 00:13:21.650 +Paul Holzinger: if I look at this, like, the even bigger problem is, like, the information provided is just false, like, + +94 +00:13:22.080 --> 00:13:24.529 +Paul Holzinger: That's the… that's the biggest problem. + +95 +00:13:26.580 --> 00:13:29.480 +Paul Holzinger: So… Yeah. + +96 +00:13:31.020 --> 00:13:37.690 +Paul Holzinger: I don't know, yeah, like, sub-projects listed, like Seamrun, for example, or Podman Desktop, like, this is not… + +97 +00:13:38.740 --> 00:13:42.510 +Paul Holzinger: They are definitely not sub-projects from us, like, this is just… + +98 +00:13:43.940 --> 00:13:47.659 +Paul Holzinger: Yeah, needs to be withdrawn, basically, based on that alone. + +99 +00:13:48.830 --> 00:13:58.350 +brent: Am I correct that we actually documented that the submission, when done, would need to be run by this group? + +100 +00:13:58.480 --> 00:13:59.060 +brent: And the. + +101 +00:13:59.060 --> 00:13:59.520 +Matthew Heon (Red Hat LLC): Yes. + +102 +00:13:59.520 --> 00:14:03.560 +brent: All need to be in… a majority would need to be in favor in order to proceed. + +103 +00:14:04.770 --> 00:14:15.220 +Matthew Heon (Red Hat LLC): Last time, we agreed as a group that a vote would be required to advance this. No vote was taken, and that decision was documented and posted to the repo. + +104 +00:14:15.380 --> 00:14:19.250 +Matthew Heon (Red Hat LLC): And relevant parties should have been in the meeting regardless, so they should have heard it. + +105 +00:14:24.060 --> 00:14:26.010 +Matthew Heon (Red Hat LLC): Alright, + +106 +00:14:27.180 --> 00:14:42.859 +Matthew Heon (Red Hat LLC): I don't think we need to do a voice vote here, but any objections, speak now or forever hold your peace, and if there are no objections, I will go ahead and request after the meeting that the CNCF, close this application, as we don't feel it's ready yet. + +107 +00:14:49.270 --> 00:14:54.869 +Paul Holzinger: Do you need… should we comment on the public issue? Or… + +108 +00:14:55.600 --> 00:15:05.559 +Matthew Heon (Red Hat LLC): If everyone is comfortable, that would be ideal. Like, I can… I can say that the core maintainers have come to a decision, and if everyone would be willing to comment after that, that'd be great. + +109 +00:15:07.690 --> 00:15:11.860 +Paul Holzinger: Yeah, because otherwise you have the same problem, it's just one person saying something. Yeah. + +110 +00:15:12.120 --> 00:15:30.380 +Matthew Heon (Red Hat LLC): I mean, we are recording this meeting, and we will have a transcript. I set the auto-transcription to on, so we can just post the transcript to the Podman repo after this happens, like we've been trying to do for the other core maintainers meeting, so we will have a record, but yeah, it would be best if we put it all in writing as well. + +111 +00:15:36.570 --> 00:15:45.929 +Matthew Heon (Red Hat LLC): Okay, I think that addresses that. Any final bits on this? Otherwise, we have… Plenty more to discuss. + +112 +00:15:48.850 --> 00:15:52.320 +Ashley Cui (Red Hat LLC): When you do that, can you link where to comment, or… + +113 +00:15:54.590 --> 00:16:00.159 +Matthew Heon (Red Hat LLC): I'll throw a link in Podman Dev when I do, how about that? + +114 +00:16:00.160 --> 00:16:01.050 +Ashley Cui (Red Hat LLC): Okay, sure. + +115 +00:16:04.170 --> 00:16:06.959 +Matthew Heon (Red Hat LLC): Okay, let's see… + +116 +00:16:07.820 --> 00:16:16.209 +Matthew Heon (Red Hat LLC): Next up would be, shared documentation repo. So, Brent raised this a while back, but he recently… + +117 +00:16:16.320 --> 00:16:20.969 +Matthew Heon (Red Hat LLC): actually went ahead and made a GitHub discussion about it, which… + +118 +00:16:21.130 --> 00:16:23.639 +Matthew Heon (Red Hat LLC): Or what's the discussion or issue? It doesn't really matter. + +119 +00:16:23.750 --> 00:16:32.390 +Matthew Heon (Red Hat LLC): So, basically the idea here is we should have a separate GitHub repo under Podman Container Tools, which will host + +120 +00:16:32.390 --> 00:16:50.609 +Matthew Heon (Red Hat LLC): a lot of the stuff that lives in Podman right now, that being the governance, the code of conduct, the security policy, how common used to be in the containers repo? Because we've sort of promoted Podman to being the top-level repo of the entire org, which it really shouldn't be. + +121 +00:16:50.930 --> 00:17:05.600 +Matthew Heon (Red Hat LLC): This is basically gonna be an entry point for people just finding things about us, and it could also make things a lot simpler, because it'll be a low-traffic repo, and people who just want to subscribe to governance issues can just subscribe to governance issues. + +122 +00:17:06.190 --> 00:17:09.170 +Matthew Heon (Red Hat LLC): Any thoughts or objections about this? + +123 +00:17:14.430 --> 00:17:17.190 +Paul Holzinger: Yeah, I would say it's maybe used it a bit… + +124 +00:17:17.599 --> 00:17:22.370 +Paul Holzinger: More for some non-governance stuff, like… yeah, start a… + +125 +00:17:22.619 --> 00:17:27.979 +Paul Holzinger: Kind of shared documentation with the… General contribution thing, like… + +126 +00:17:29.230 --> 00:17:32.270 +Paul Holzinger: Commit formats, and stuff like that. + +127 +00:17:32.420 --> 00:17:34.409 +Paul Holzinger: Which are noted in the issue, I think. + +128 +00:17:34.570 --> 00:17:38.000 +Paul Holzinger: Those could live in the same repo, it's probably easier. + +129 +00:17:39.690 --> 00:17:44.300 +Paul Holzinger: To have, like, one sample thing there instead of yet another thing. + +130 +00:18:02.760 --> 00:18:11.570 +Matthew Heon (Red Hat LLC): Okay, it sounds like we all agree this is a good idea. Anyone want to take this one on? Brent, I know you were talking about potentially doing it, would you be willing? + +131 +00:18:16.620 --> 00:18:17.670 +brent: Can you hear me now? + +132 +00:18:18.090 --> 00:18:19.240 +Matthew Heon (Red Hat LLC): Yeah, we can hear you. + +133 +00:18:19.240 --> 00:18:24.820 +brent: Okay, I… this thing doesn't tell me whether I'm on mute or not, it just clicks. + +134 +00:18:25.670 --> 00:18:32.479 +brent: I wanted to sort of see if anyone else wanted to do it. If not, I can be the default assignee. + +135 +00:18:33.220 --> 00:18:40.900 +brent: I think we need to determine what it's called as a group before, you know, I can actually start creating it, but… + +136 +00:18:41.180 --> 00:18:46.970 +brent: Given that I have, org privileges and whatnot, it probably makes sense. + +137 +00:18:49.850 --> 00:18:53.800 +Matthew Heon (Red Hat LLC): At the very least, you can make the repo, and then someone else can populate it. + +138 +00:18:54.380 --> 00:18:56.640 +Mohan Boddu (Red Hat LLC): I was about to say, if you can, + +139 +00:18:57.390 --> 00:19:03.579 +Mohan Boddu (Red Hat LLC): create the repo, or if one of the core maintainers can create the repo, I can populate the contents. + +140 +00:19:05.590 --> 00:19:15.829 +Mohan Boddu (Red Hat LLC): I mean… Perfect. Somewhere it said, like, it's core maintainers in the issue, so as long as it's okay coming from a community manager, I'm more than happy to take it. + +141 +00:19:16.460 --> 00:19:21.070 +brent: Yeah, I'll work with you then, Mohan. It's… if you're agreeable, then… + +142 +00:19:21.170 --> 00:19:30.849 +brent: Matt, we've got our assignees. If anyone has a brilliant suggestion for a repo name, I'd love to hear it. Otherwise, I'll probably start a + +143 +00:19:31.670 --> 00:19:35.980 +brent: discussion on Podman like we did with, OrgName. + +144 +00:19:36.670 --> 00:19:37.540 +Laura Santamaria (Red Hat): So… + +145 +00:19:37.730 --> 00:19:48.070 +Laura Santamaria (Red Hat): I'll just chime in here and say that it's a very common pattern to use the community name. I commented on the issue as well. + +146 +00:19:48.320 --> 00:20:00.680 +Laura Santamaria (Red Hat): we'll see this in a bunch of different places. If you would like to see some of the commands I used to start doing it for the Bootsy group, we're doing the same thing for them. So, happy to share, what we're doing there as, + +147 +00:20:00.930 --> 00:20:04.139 +Laura Santamaria (Red Hat): We collect information in one place for them as well. + +148 +00:20:04.670 --> 00:20:07.249 +Laura Santamaria (Red Hat): So, but I would recommend just calling it community. + +149 +00:20:08.790 --> 00:20:13.519 +brent: Perfect. I'm agreeable to that. Does anyone object? Otherwise, we can run with that. + +150 +00:20:14.840 --> 00:20:15.980 +Matthew Heon (Red Hat LLC): Sounds good to me. + +151 +00:20:17.340 --> 00:20:18.839 +brent: That was Laura, thank you. + +152 +00:20:19.930 --> 00:20:20.800 +Laura Santamaria (Red Hat): It was. + +153 +00:20:22.110 --> 00:20:22.820 +brent: Thank you. + +154 +00:20:23.420 --> 00:20:26.650 +Ashley Cui (Red Hat LLC): Yep, and I'm also happy to help if you need, anything. + +155 +00:20:27.290 --> 00:20:29.350 +brent: Okay, I'll huddle us together. + +156 +00:20:32.100 --> 00:20:36.600 +Matthew Heon (Red Hat LLC): Alright, sounds good. We have assignees for that. Thank you, everyone. + +157 +00:20:38.540 --> 00:20:49.269 +Matthew Heon (Red Hat LLC): All right, anything else on this? Otherwise, we can move on to moving the remaining repos into the, what do you call it, CNCF work. So, we had… + +158 +00:20:49.270 --> 00:20:57.359 +Matthew Heon (Red Hat LLC): Last time we agreed we were going to move a bunch of stuff in. We are, I would say, about halfway done. Everything that needed CI got moved in. + +159 +00:20:57.360 --> 00:21:09.580 +Matthew Heon (Red Hat LLC): But we did not yet get to some of the important ones. Podman.io, Build.io, so both the websites, Automation Images, or not Automation, sorry, Image Build. + +160 +00:21:09.680 --> 00:21:15.760 +Matthew Heon (Red Hat LLC): ImageBuild has a PR opens, but it needs comments. Let me find a link for that one. + +161 +00:21:16.080 --> 00:21:23.839 +Matthew Heon (Red Hat LLC): And I am probably forgetting a few. Anyone remember the other ones that were supposed to move in, besides the websites? + +162 +00:21:27.040 --> 00:21:33.890 +Paul Holzinger: There's a small one, go.podman.io, for the… Like, Go imports. + +163 +00:21:37.240 --> 00:21:42.829 +Paul Holzinger: And… Yeah, I think only the website and the image grid right now. + +164 +00:21:43.890 --> 00:21:46.109 +Paul Holzinger: Don't think we need others at the moment. + +165 +00:21:47.860 --> 00:21:48.640 +Matthew Heon (Red Hat LLC): Okay. + +166 +00:21:49.740 --> 00:21:55.379 +Matthew Heon (Red Hat LLC): I can probably continue to take the lead on these, if people don't mind. + +167 +00:21:55.630 --> 00:22:02.579 +Matthew Heon (Red Hat LLC): I think I've got the process down now, and it doesn't take much besides poking people. Tom, sorry. + +168 +00:22:03.150 --> 00:22:07.659 +Tom Sweeney (Red Hat LLC): Do we have any requirements with CNCF before we start stashing stuff in there? + +169 +00:22:09.250 --> 00:22:13.790 +Matthew Heon (Red Hat LLC): I think we're fine as long as it matches the license, and… + +170 +00:22:14.060 --> 00:22:24.570 +Matthew Heon (Red Hat LLC): as long as it… the process we set up says it has to be fundamentally related to Podman, it has to match license, it has to match governance, and it has to be, + +171 +00:22:24.740 --> 00:22:32.130 +Matthew Heon (Red Hat LLC): well-maintained and well-written project. I think that's the broad guidance we left ourselves. + +172 +00:22:33.570 --> 00:22:36.569 +Paul Holzinger: And it needs to be voted in by the core maintainers. + +173 +00:22:37.070 --> 00:22:38.119 +Paul Holzinger: Yeah, that's fine. + +174 +00:22:39.820 --> 00:22:42.120 +Tom Sweeney (Red Hat LLC): Have we officially voted for these guys? + +175 +00:22:42.770 --> 00:22:44.750 +Matthew Heon (Red Hat LLC): Not yet, that would be part of the move. + +176 +00:22:44.750 --> 00:22:45.340 +Tom Sweeney (Red Hat LLC): Okay. + +177 +00:22:47.860 --> 00:22:49.400 +Matthew Heon (Red Hat LLC): Mohan. + +178 +00:22:49.400 --> 00:22:57.490 +Mohan Boddu (Red Hat LLC): Yeah, Matt, you and I kind of discussed about this after I came back from the PTO, like, thinking of network and artwork, so, + +179 +00:22:58.310 --> 00:23:03.970 +Mohan Boddu (Red Hat LLC): I know we thought, like, it's better to merge them before moving here. + +180 +00:23:04.220 --> 00:23:08.720 +Mohan Boddu (Red Hat LLC): Just wanted to bring it up if it is still the plan, or… I know we haven't… + +181 +00:23:09.610 --> 00:23:13.850 +Mohan Boddu (Red Hat LLC): Formally brought it up to the team or anything, it's just a random discussion we had. + +182 +00:23:14.140 --> 00:23:16.230 +Mohan Boddu (Red Hat LLC): I just want to bring it up here as well. + +183 +00:23:17.340 --> 00:23:29.260 +Matthew Heon (Red Hat LLC): I think it's a good idea. I do… I would wait until we merge the repos. It seems like it'd be extra effort to put two of them in, and then take it down to one at some later point when we merge them, so… + +184 +00:23:33.050 --> 00:23:39.749 +Paul Holzinger: I don't mind that much, but I don't really see a reason why they need to be moved at the moment. + +185 +00:23:40.960 --> 00:23:46.299 +brent: And I am not in favor of doing that. I've been… I've been on the record about that. + +186 +00:23:50.130 --> 00:23:50.780 +Matthew Heon (Red Hat LLC): Alright. + +187 +00:23:50.920 --> 00:23:53.460 +Matthew Heon (Red Hat LLC): Let's hold off on those until we have… + +188 +00:23:53.580 --> 00:23:56.670 +Matthew Heon (Red Hat LLC): What do you call it? A better idea of what's going on, then. + +189 +00:24:00.620 --> 00:24:09.120 +Matthew Heon (Red Hat LLC): Okay, anything else on repo moves? Otherwise, I believe we have… One more topic. + +190 +00:24:11.240 --> 00:24:22.229 +Matthew Heon (Red Hat LLC): Audit of maintainer files. So it is about time for our quarterly audit of who's actually an active maintainer, and maybe we should move some of these people, out. + +191 +00:24:22.510 --> 00:24:36.290 +Matthew Heon (Red Hat LLC): Anyone want to volunteer to go through the maintainer files and propose anyone who's inactive for either removal or reduction to a more suitable role? + +192 +00:24:48.270 --> 00:24:52.010 +Matthew Heon (Red Hat LLC): I am willing to take this if no one else wants it, but . + +193 +00:24:57.620 --> 00:24:58.250 +brent: I don't think you're… + +194 +00:24:58.250 --> 00:24:58.589 +Matthew Heon (Red Hat LLC): figure it out. + +195 +00:24:58.590 --> 00:24:59.300 +brent: argument. + +196 +00:25:01.490 --> 00:25:11.929 +Matthew Heon (Red Hat LLC): All right, through the astounding confidence of the core maintainers, I have been voted in to examine all of our repos and propose some folks for removal. + +197 +00:25:12.170 --> 00:25:16.329 +Matthew Heon (Red Hat LLC): If they are not at… no longer active maintainers, I should say. + +198 +00:25:17.750 --> 00:25:24.940 +Matthew Heon (Red Hat LLC): Alright, that was the last topic I had on the agenda. Anyone else have anything they'd like to discuss? + +199 +00:25:34.130 --> 00:25:36.779 +Matthew Heon (Red Hat LLC): I'm hearing a whole lot of nothing. Alright. + +200 +00:25:36.890 --> 00:25:40.560 +Matthew Heon (Red Hat LLC): Thank you everyone for attending. + +201 +00:25:40.960 --> 00:25:54.860 +Matthew Heon (Red Hat LLC): Once this is done, I will try and figure out how to get the transcript and post the, what do you call it? Post the minutes to the Podman repo, which eventually this should all move into the community repo, but oh well, we can do that later. + +202 +00:25:54.970 --> 00:26:00.109 +Matthew Heon (Red Hat LLC): Anyways, thank you everyone for attending, and I will see y'all later. + +203 +00:26:00.790 --> 00:26:01.739 +Matthew Heon (Red Hat LLC): Bye, folks. + +204 +00:26:04.400 --> 00:26:05.160 +Mohan Boddu (Red Hat LLC): Bye, Al. diff --git a/minutes/README.md b/minutes/README.md new file mode 100644 index 0000000..d1d7312 --- /dev/null +++ b/minutes/README.md @@ -0,0 +1,3 @@ +# Core Maintainer minutes + +This directory is for documenting minutes from the core maintainer meetings.