diff --git a/404.html b/404.html index 88d763f01..3b54fa573 100644 --- a/404.html +++ b/404.html @@ -17,7 +17,7 @@
-
Skip to main content
Not Found

We don't sea that page.

We could not find what you were looking for:   isn't a working link.
The content may have moved;  try a search for it

+
Skip to main content
Not Found

Oh no! We can't seal the deal!

We could not find what you were looking for:   isn't a working link.
The content may have moved;  try a search for it

diff --git a/community.html b/community.html index 034701fb0..f68f93de6 100644 --- a/community.html +++ b/community.html @@ -17,7 +17,7 @@
-
Skip to main content

Community

Podman Logo

Chat with the Podman community

The Podman developers are generally around during CEST and Eastern Time business hours, so please be patient if you’re in another time zone!

Current Time

22:14

Central European Standard Time

17:14

Eastern Daylight Time

Podman Community Meetings

An image of podman team members in a virtual meeting

Older meeting details

Attendees: Ralph Bean, Sumantro Mukherjee, Chris Evich, Dan Walsh, Ashley Cui, Neil Smith, Paul Holzinger, Lokesh Mandvekar, Ashley Cui, and others not noted.

Older meeting details

Mailing List

Browse the mailing list

Simply visit [the Podman mailing list website](https://lists.podman.io/) to browse or search previous postings to the Podman mailing list.

Subscribe or post to the mailing list

A screenshot of the Podman mailing list home screen.

Submitting Issues & Pull Requests

Submitting Issues

Don't include private / sensitive info in issues!

  • Feel free to add your scenario, or additional information, to the discussion.
  • Subscribe to the issue to be notified when it is updated.
  • Include as much detail as possible
  • Try to remove any extra stuff that doesn't really relate to the issue itself

Submitting Pull Requets

While bug fixes can first be identified via an "issue", 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.
  • Additional testcases. Ideally m they should fail w/o your code change applied.
  • Documentation changes.
More PR Submission Details

Special thanks to our contributors

The Podman community has contributors from many different organizations, including:

Red Hat LogoAmadeus LogoSuse LogoMotorola Solutions LogoNTT LogoIBM LogoDebian Logo
+
Skip to main content

Community

Podman Logo

Chat with the Podman community

The Podman developers are generally around during CEST and Eastern Time business hours, so please be patient if you’re in another time zone!

Current Time

22:17

Central European Standard Time

17:17

Eastern Daylight Time

Podman Community Meetings

An image of podman team members in a virtual meeting

Older meeting details

Attendees: Ralph Bean, Sumantro Mukherjee, Chris Evich, Dan Walsh, Ashley Cui, Neil Smith, Paul Holzinger, Lokesh Mandvekar, Ashley Cui, and others not noted.

Older meeting details

Mailing List

Browse the mailing list

Simply visit [the Podman mailing list website](https://lists.podman.io/) to browse or search previous postings to the Podman mailing list.

Subscribe or post to the mailing list

A screenshot of the Podman mailing list home screen.

Submitting Issues & Pull Requests

Submitting Issues

Don't include private / sensitive info in issues!

  • Feel free to add your scenario, or additional information, to the discussion.
  • Subscribe to the issue to be notified when it is updated.
  • Include as much detail as possible
  • Try to remove any extra stuff that doesn't really relate to the issue itself

Submitting Pull Requets

While bug fixes can first be identified via an "issue", 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.
  • Additional testcases. Ideally m they should fail w/o your code change applied.
  • Documentation changes.
More PR Submission Details

Special thanks to our contributors

The Podman community has contributors from many different organizations, including:

Red Hat LogoAmadeus LogoSuse LogoMotorola Solutions LogoNTT LogoIBM LogoDebian Logo