Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updated Contributing.txt with more details #7990

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Updated Contributing.txt with more details #7990

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
791dec2
Update CONTRIBUTING.rst
mdsahilnoob Dec 21, 2023
8573667
Update CONTRIBUTING.rst
mdsahilnoob Dec 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
25 changes: 17 additions & 8 deletions CONTRIBUTING.rst
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, this mostly feels more verbose without actually adding anything. @webknjaz Any thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, agreed. We don't want an entire Git tutorial or things that are documented elsewhere to be copy-and-pasted there since this is an additional maintenance burden to keep copies in sync.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, there's a copy of this document in our Sphinx docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I typically keep something short like https://ansible-pylibssh.rtfd.io/en/latest/contributing/guidelines/, but in some cases, it makes sense to give more examples: https://github.com/python-attrs/attrs/blob/main/.github/CONTRIBUTING.md.

Still, I don't like trying to maintain the same thing somebody else does.

Original file line number Diff line number Diff line change
Expand Up @@ -12,21 +12,30 @@ I hope everybody knows how to work with git and github nowadays :)

Workflow is pretty straightforward:

1. Clone the GitHub_ repo using the ``--recurse-submodules`` argument
Clone the Repository:
- 1.Open the provided GitHub link and click the "Fork" button on the upper-right of the web page to create your fork.
- 2.Clone your forked repository using the --recurse-submodules argument to ensure submodules are also cloned.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks the syntax highlighting.


2. Setup your machine with the required development environment
Set Up Development Environment:
- 1.Configure your machine with the necessary development environment as specified in the project's documentation.

3. Make a change
Make Changes:
- 1.Implement the desired changes in your local clone.

4. Make sure all tests passed
Run Tests:
- 1.Ensure all tests pass before proceeding to the next step.

5. Add a file into the ``CHANGES`` folder, named after the ticket or PR number
Update Changes File:
- 1.Add a file to the CHANGES folder, naming it after the ticket or pull request number.

6. Commit changes to your own aiohttp clone
Commit Changes:
- 1.Commit your changes to your own aiohttp clone.

7. Make a pull request from the github page of your clone against the master branch
Create Pull Request:
- 1.Make a pull request from the GitHub page of your clone against the master branch of the original repository.
Optional Backport:

8. Optionally make backport Pull Request(s) for landing a bug fix into released aiohttp versions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line should probably be changed though to better reflect current practices.

Maybe something like:
Once merged, backports may be created automatically by a bot. If the bot fails to do this, please follow the instructions from the bot to complete the backport PRs.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, i will check that, thanks for the information!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That only works if somebody reviewing the PR puts the labels on. The contributors might still want to optionally offer manually-crafted backport PRs. (or semi-manually — we have a config for the CPython's cherry-picker tool!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm just thinking it's usually safer to wait for the bot. A maintainer should add the label when they believe a backport is needed. Surely cherry picking won't work well if done before merging anyway, as they'd be picking commits from the branch, which won't end up on master (there will just be a squash commit instead).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the bot experiences instability because of #4581, that I haven't really had time to tackle properly. I think it needs to be prioritized but there's a lot on my plate right now. A workaround is to re-apply the label (but for that, one must notice the failure first).

Optionally, create backport pull requests if you are fixing a bug that needs to be applied to released aiohttp versions.

.. important::

Expand Down