-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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.
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
Updated Contributing.txt with more details #7990
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, i will check that, thanks for the information! There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:: | ||
|
||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.