Revamp the contributor guide #473

greg0ire · 2023-01-24T21:14:42Z

While some sections feel redundant, other sections were missing, like
the one about choosing the right branch.

This only addresses the first question of #472

@mpdude please review.

SenseException

I'd like to see more reviewers for this.

source/contribute.rst

mpdude · 2023-01-24T22:13:47Z

I‘ll have to review the branch selection rules later, with a clear mind.

In general, I'd say there is a lot of information in this chapter that should be routine for people familiar with git.

Do we really need to provide all that? Do we anticipate contributions from users who haven’t done all that before?

greg0ire · 2023-01-25T14:34:15Z

Do we really need to provide all that? Do we anticipate contributions from users who haven’t done all that before?

There's indeed pretty basic stuff, so we could remove more than I already did. That being said, here are the most common issues I see:

people who develop directly on 2.3.x instead of creating a topic branch, and are then are asked to retarget on 2.4.x
people who don't know they can force push and instead close their PR and open a new one when asked to retarget their branch
bad commit messages (typically fix for #1234, where they don't explain what they did and how that's supposed to fix anything)
good commit message body, and commit message subject as suggested by github, so typically "Update path/to/file.php"
non-atomic commits, with unexplained changed mixed with changes relating to the main topic of the pull request
PR that passes the build, but with commits that don't pass the build individually
commits that don't bring extra understanding of what's being done but rather show the struggle ("fix cs")

greg0ire · 2023-03-06T12:55:51Z

ping @mpdude 🙂

source/contribute.rst

I personally use origin for the official repository. Let us avoid "origin" entirely, as it might lead to some confusion.

Not everyone wants to contribute directly, some people might want to toy with the repository before deciding to fork.

mpdude · 2023-03-07T16:02:01Z

Still have to go through the textual changes.

Regarding the other points you brought up:

When we ask people to re-target PRs, can we expect/assume they find these instructions?

Would it help if we set up a canned reply in GitHub, so that when we ask people to change the target branch we could include a pointer to this documentation?

Regarding bad commit messages, meaningless commits etc.: Would it make sense to discuss squash-merging commits like Symfony does? That would help to hide “how the sausage is being made” and have a clean history with one commit per change (= PR).

source/contribute.rst

mpdude · 2023-03-07T22:55:48Z

source/contribute.rst

+
+The general rules are as follows:
+
+- Patch releases should be as stable as possible. They fix bugs, but in


mpdude · 2023-03-07T22:59:57Z

source/contribute.rst

+If you are touching something outside the source directory (usually
+``src``, sometimes ``lib``), and that thing is not ``composer.json``,
+you should probably target the lowest branch.
+There is no way that your contribution is going to create a bug for
+the end user, so let us get it on all 3 branches with merges up.
+Examples are: documentation, tests, build scripts, tooling configuration.
+
+If you are touching something inside the source directory, you may
+still contribute to the lowest branch if it is a bug fix, and if you
+are touching comments that are not phpdoc comments.
+
+If the comments are phpdoc comments… it depends. If the phpdoc was
+inaccurate, you should target the lowest branch. If the phpdoc was
+imprecise but technically correct, you should target the next minor
+branch.


Things that can go on the patch release branch include:

Bugfixes 🥹

Adding tests, especially for bugs fixed

Updates, corrections or improvements to non-code assets like documentation, build scripts or tooling configuration

Updates, corrections or improvements to code comments that are not phpdoc comments (docblock type hints etc.)

Fixes to incorrect phpdoc comments

When phpdoc comments are imprecise but not wrong technically, target the next minor release branch instead.

mpdude · 2023-03-07T23:04:51Z

source/contribute.rst

+If you are doing a refactoring and you think you didn't change the
+behavior of the code, you should still target the next minor branch
+unless the refactoring is necessary for a bugfix. Let us not take any
+unnecessary risks.
+
+If you want to deprecate something, you should target the next minor
+branch: upgrading to a new patch version should not result in any
+additional deprecations.
+
+If you want to add a new feature, you should target the next minor
+branch, because it might have unintentional side effects that break existing code.


The next minor version branch may include:

Refactorings, unless they are necessary for bugfixes. This is to avoid unnecessary risks.

Adding deprecations – remember to update the UPGRADE.md file as well!

Adding new features and/or public APIs

What about changing minimum dependency requirements?

Changing minimum dependency requirements is OK on a patch branch if it's absolutely necessary to fix a bug. I don't think that's often the case, and I think we don't have to mention this here.

mpdude · 2023-03-07T23:09:49Z

source/contribute.rst

+If you want to remove or change a public API, you should target the next
+major branch. If you change a public API, you should provide an upgrade
+path for the end user. Ideally, you should make the new API available on
+the next minor branch, deprecate the old API, and remove it in the next
+major.


On the next major version branch, usually only deprecations notices, deprecated features and necessary compatibility layers are being removed.

Avoid suprising changes in public APIs on the next major version branch if anyhow possible. In order to provide a smooth upgrade path to users, the preferred solution is to add deprecations and possibly alternative APIs in a preceding minor version, and only remove the deprecations and compatibility layers in the next major release.

source/contribute.rst

mpdude · 2023-03-07T23:14:01Z

source/contribute.rst

+1. Fetch all new commits: `git fetch doctrine``.
+2. Rebase on what you fetched interactively:
+   ``git rebase --interactive doctrine/2.3.x # use -i for short``
+3. A window will show up with many lines, remove every line but the last
+   ones, which should correspond to your commits.
+4. If you run into a conflict, fix it with ``git mergetool``, then
+   continue on your merry way with ``git rebase --continue``.
+5. Force push to overwrite the previous version : ``git push --force``.


Rebases will lose approvals. Just sayin'.

The paragraph is "typically because the build had an issue", and I personally don't approve pull requests that have a red build.

mpdude · 2023-03-09T05:39:27Z

source/contribute.rst

+  must be available in the minor release that adds the deprecation for
+  the old feature.
+
+With that in mind:


Here we have two sentences that end with a colon

source/contribute.rst

mpdude · 2023-03-09T07:12:46Z

source/contribute.rst

+about that
+<https://docs.github.com/en/get-started/quickstart/contributing-to-projects>`_
+first.
+


When following that documentation, you'll end up with a clone of your fork, so origin refers to that. Also, in these instructions, only the default branch from the base repo will be included in the clone.

So, maybe we should add instructions here to add doctrine as a second remote pointing to the upstream (original) Doctrine repo, and to pull all branches from there?

Or to rename it… should be less confusing.

Remember, we are writing this mostly for an audience with little to no experience in contributing on GitHub. So we should try to leave them with a setup that is as “mainstream” as possible.

I don't know that there is a mainstream setup. Some people use origin for their forks, some other for the upstream repository… I don't have statistics on that.

Here is an example of origin pointing to forks: https://symfony.com/doc/current/contributing/documentation/overview.html#your-first-documentation-contribution

Or to rename it… should be less confusing.

I think I misunderstood this, I thought you wanted to rename origin to something else.

I agree, there are people who clone the original repo and add their fork as a second remote, or they clone their fork and add upstream or similar.

Either way, wouldn't it be safe if we suggest to add a doctrine remote pointing to the original Doctrine project's repo, and use that remote name in all other git commands?

I just see that in fact, you do that – rename origin to doctrine. That may be wrong, depending on how people set up their clone. And if they follow the GitHub instruction linked above, it will definetly be wrong, since those instructions end up with origin= the fork.

@greg0ire I think this point still needs to be addressed:

Simply renaming origin to doctrine may not be correct. Depending on how people obtained their clone, origin may be their fork or the original (upstream) repo.

When closely following the instructions linked in the previous sentence, then origin will be the fork, so the rename suggested here is definetly wrong.

I think I addressed it now. I suggested starting afresh with a git remote rm

mpdude · 2023-03-09T07:19:56Z

source/contribute.rst

+Time might have elapsed since the last time you contributed or since you
+cloned the repository. You might want to fetch the latest changes from
+the ``doctrine`` remote:

 .. code-block:: console

    $ git fetch doctrine


Let's move that a bit down

Disagree, see #473 (comment)

source/contribute.rst

mpdude · 2023-03-09T07:25:31Z

source/contribute.rst

+-------------------------
+
+New pull requests are created with the repository's default branch as
+base branch, and that might not be what you want. Make sure to pick the


The base branch should be what you chose according to the guidelines mentioned in the beginning of this chapter. It is also the branch name that you provided when you created your topic branch.

mpdude · 2023-03-09T07:26:28Z

source/contribute.rst

+New pull requests are created with the repository's default branch as
+base branch, and that might not be what you want. Make sure to pick the
+correct branch when creating the pull request. If you do not, it can
+still be changed afterwards.


That'a a bit hidden – on GitHub, you have to click "Edit" next to the pull request title to change the title and base branch

mpdude · 2023-03-09T07:29:20Z

source/contribute.rst

-.. code-block:: console
+Sometimes, you will need to rebase your branch on the latest changes,
+typically because the build had an issue unrelated to your changes, and
+that issue has been fixed after you created your branch.


Basically, a ebase takes all changes on your topic branch and moves them to another starting point. This starting point was the Doctrine branch that you chose when you created your topic branch, at that point in time. The rebase will move your changes to be based on the current state of this branch.

mpdude · 2023-03-09T07:32:47Z

source/contribute.rst

+3. A window will show up with many lines, remove every line but the last
+   ones, which should correspond to your commits.


Hm, that's pretty vague, and every line removed potentially is a lost commit. A nice footgun, eh?

As long as you're only rebasing on the same branch that you initially started out with, does it have to be an interactive rebase at all?

(Assuming we're writing all this for people rather new to git and contributing on GitHub, so we should not talk them into complicated situations where they might lose work and/or get frustrated)

As long as you're only rebasing on the same branch that you initially started out with, does it have to be an interactive rebase at all?

That's the thing, newbies will often pick the wrong branch, and might have to rebase on another branch, and commit they don't own. I'll reword with "commits that you did not author"

Ah but the paragraph is not about this use case. You're right, let's make this non-interactive, I've been mixing things up.

Let’s have a dedicated section about changing the target branch and the rebase operations that are necessary for this.

Additionally, prepare a canned reply that we can use in PRs whenever we ask people to change the target branch. This should point to that documentation, mention the correct branch and tell people that they need not close the PR but can update it.

mpdude

IMHO this is already in a very good shape, keep going!

Added a next round of feedback – sorry I missed some of the points last time.

mpdude · 2023-03-09T07:41:44Z

Regarding #473 (comment)

bad commit messages (typically fix for #1234, where they don't explain what they did and how that's supposed to fix anything)

good commit message body, and commit message subject as suggested by github, so typically "Update path/to/file.php"

non-atomic commits, with unexplained changed mixed with changes relating to the main topic of the pull request

PR that passes the build, but with commits that don't pass the build individually

commits that don't bring extra understanding of what's being done but rather show the struggle ("fix cs")

IMHO squash-merging PRs could solve all those problems. We could also ask contributors to keep the initial PR description an up-to-date description and summary of the change and use that as the commit message for the merge. Symfony does it that way as well.

Where and how could this best be discussed with the relevant decision-makers from the Doctrine core team?

mpdude · 2023-03-09T13:26:11Z

source/contribute.rst

+The default branch is the branch you see when you enter the repository
+page on GitHub.
+
+.. image:: ../images/default-branch.png
+   :alt: The default branch
+   :style: margin-bottom: 20px
+
+In this DBAL example, it's the branch with the name **2.11.x**. The
+branch name reflects the current lowest supported version of a
+repository.


Relevant information?

Are you asking if this sentence is relevant, or do you want me to add relevant information?

mpdude · 2023-03-09T13:27:26Z

source/contribute.rst


-Sync your local 2.11.x branch:
+1. Fetch all new commits: `git fetch doctrine``.


Switch to the branch you'd like to rebase.

mpdude · 2023-03-09T13:28:04Z

source/contribute.rst

+1. Fetch all new commits: `git fetch doctrine``.
+2. Rebase on what you fetched:
+   ``git rebase doctrine/2.3.x``
+3. If you run into a conflict, fix it with ``git mergetool``, then


Never used git mergetool – does that include git add for the resolved conflicts?

Yes. I'll try to rework this.

mpdude · 2023-03-09T13:42:06Z

source/contribute.rst

+against ``2.3.x`` but you are told to change it to ``2.4.x``. In that
+case, if ``2.4.x`` does not have all the commits that ``2.3.x`` has, you
+need to drop these commits while rebasing: it is not your responsibility
+to merge them up.


Good point, I was not aware of that!

~~Wait, subconsciously I was.~~

git checkout my-topic git rebase doctrine/2.3.x --onto doctrine/2.4.x

~~No need to pick the right commits. Am I missing something?~~

I should read your full changes before jumping in, you've mentioned this below.

Isn't that much easier and safe?

You're probably right, let's just suggest that one method.

When using that method, the "commits you did not author" thingy is not a issue at all, right? If so, we need not mention it.

Another case where you need a rebase is when you want to change the
target branch of your PR. For instance, you might have created your PR
against 2.3.x but you are told to change it to 2.4.x. In that
case, the following command will pick all changes that you made against the 2.3.x branch, and re-apply them on the current 2.4.x branch.

$ git fetch doctrine
$ git rebase --onto doctrine/2.4.x doctrine/2.3.x your-topic-branch
$ git push --force

After that, you also need to update the GitHub pull request to point to the new target branch. You can do so by clicking on the "Edit" button next to the pull request title. After you changed the target branch, the pull request should only show your commits and changes, but this time they are based on the new target branch.

When using that method, the "commits you did not author" thingy is not a issue at all, right? If so, we need not mention it.

Not an issue indeed 👍

mpdude · 2023-03-09T13:46:23Z

source/contribute.rst

-``rebase --continue``. At any stage, you can abort the rebase with
-``rebase --abort`` unlike nasty merges which will leave files strewn
-everywhere.
+On upstream changes


"on" or "onto"? Not a native speaker myself. Git CLI suggests onto.

From man git rebase: "it may not be the best idea to keep rebasing on top of the upstream"

mpdude · 2023-03-09T13:47:10Z

source/contribute.rst

+   ``drop``.
+4. If you run into a conflict, fix it with ``git mergetool``, then
+   continue on your merry way with ``git rebase --continue``.
+5. Force push to overwrite the previous version : ``git push --force``.



Update the Pull Request target in GitHub

Already mentioned above (and I think it's best to do it before pushing)

mpdude · 2023-03-09T13:48:24Z

Sorry for all the nitpicking, I owe you a beer once we happen to meet IRL

greg0ire · 2023-03-09T15:27:25Z

Can't wait for the next EU-FOSSA hackathon!

mpdude · 2023-03-09T15:32:24Z

Oh good ol' times

greg0ire · 2023-04-13T17:53:52Z

@mpdude IMO this is ready, can I get a formal approval from you? @SenseException , would it be sufficient for you or do you wish to get other maintainers to review this? I'd hate to let this rot…

SenseException · 2023-04-13T20:48:06Z

Yes, @mpdude fits perfectly as second reviewer. His approval should make this getting merged. 👍

mpdude · 2023-04-14T09:24:25Z

source/contribute.rst

+When cloning, you will end up with a remote called ``origin``. This can
+be confusing because sometimes, people use ``origin`` to refer to their
+fork.
+
+To avoid confusion, we recommend you to rename the ``origin`` remote to
+``doctrine``:

 .. code-block:: console

-    $ git clone git@github.com:username/dbal.git
+    $ git remote rename origin doctrine

-  Enter the dbal directory and add the **doctrine** remote
+Also, please ensure your Github fork is known as ``fork`` locally:

 .. code-block:: console

-    $ cd dbal
-    $ git remote add doctrine git://github.com/doctrine/dbal.git
+    $ git remote add fork git@github.com:<your-name-here>/orm.git


Suggestion for this entire section:

To make the example commands given in the rest of this page less ambiguous, we will add two explicit names for remote Git repositories: `doctrine` for the original Doctrine project you're contributing to, and `fork` for your fork of it. .. code-block:: console $ [`cd` into the directory created by `git clone ...`] $ git remote add doctrine git@github.com:doctrine/<name-of-project>.git $ git remote add fork git@github.com:<your-github-name>/<name-of-project>.git

mpdude · 2023-04-14T09:30:12Z

source/contribute.rst

+.. note::
+
+   Here, we assume ``doctrine`` points to the upstream repository, and
+   not your fork. If you are not sure, you can check with ``git remote -v``.


~~We don't need this note since we've added the remote name in the beginning section.~~

"Remember, we assume that doctrine points to the original Doctrine project repository and not to your fork, as described in the initial section of this page. If unsure, you can check with git remote -v.

mpdude · 2023-04-14T09:40:31Z

source/contribute.rst

-Finished topic branches should be pushed to **origin** for a
-**maintainer** to review and pull into **doctrine** as appropriate:
+1. Switch to the branch you would like to rebase.
+2. Fetch all new commits: `git fetch doctrine``.


Is this missing a backtick?

mpdude · 2023-04-14T09:52:14Z

@greg0ire Done. Can you easily follow up on the new comments I made? Otherwise, I'll walk you through them one by one.

Not much left – let's push this over the finish line soon!

greg0ire · 2023-04-14T10:14:31Z

Can you easily follow up on the new comments I made? Otherwise, I'll walk you through them one by one.

I think I did, but I also think I might have easily missed some comments. Can you mark the resolved ones as such?

mpdude · 2023-04-14T13:12:11Z

For some reason, I cannot mark (everything) as "resolved" 🤔 .

Let's see:

Revamp the contributor guide #473 (comment)

mpdude · 2023-04-14T13:28:52Z

source/contribute.rst

-date with the following command:
+To make the example commands given in the rest of this page less
+ambiguous, we will add two explicit names for remote Git repositories:
+`doctrine` for the original Doctrine project you're contributing to, and


.rst need double backticks here and in the following lines?

While some sections feel redundant, other sections were missing, like the one about choosing the right branch.

mpdude · 2023-04-14T13:34:30Z

All comments addressed ✅ .

Awesome work @greg0ire 🥇 and sorry it took so many iterations. I really like the result!

greg0ire · 2023-04-14T13:43:37Z

Thanks for the thorough review!

SenseException approved these changes Jan 24, 2023

View reviewed changes

source/contribute.rst Outdated Show resolved Hide resolved

greg0ire force-pushed the how-to-choose-a-branch-improvements branch 2 times, most recently from db7abfa to a10c250 Compare January 24, 2023 22:52

mpdude reviewed Mar 6, 2023

View reviewed changes

source/contribute.rst Outdated Show resolved Hide resolved

mpdude reviewed Mar 6, 2023

View reviewed changes

source/contribute.rst Show resolved Hide resolved

greg0ire added 2 commits March 6, 2023 23:30

Use a more explicit remote name

b023b9d

I personally use origin for the official repository. Let us avoid "origin" entirely, as it might lead to some confusion.

Use a more straightforward setup method

331e42d

Not everyone wants to contribute directly, some people might want to toy with the repository before deciding to fork.

mpdude reviewed Mar 7, 2023

View reviewed changes

source/contribute.rst Show resolved Hide resolved

mpdude reviewed Mar 7, 2023

View reviewed changes

source/contribute.rst Outdated Show resolved Hide resolved

greg0ire force-pushed the how-to-choose-a-branch-improvements branch 2 times, most recently from 1515a5e to 7bc40bc Compare March 7, 2023 22:26

mpdude reviewed Mar 7, 2023

View reviewed changes

mpdude mentioned this pull request Mar 7, 2023

Things I wish I had known as a new contributor #472

Open

greg0ire force-pushed the how-to-choose-a-branch-improvements branch from 7bc40bc to f06ca12 Compare March 8, 2023 07:55

greg0ire requested a review from mpdude March 8, 2023 19:50

mpdude reviewed Mar 9, 2023

View reviewed changes

source/contribute.rst Show resolved Hide resolved

mpdude reviewed Mar 9, 2023

View reviewed changes

source/contribute.rst Show resolved Hide resolved

mpdude reviewed Mar 9, 2023

View reviewed changes

greg0ire force-pushed the how-to-choose-a-branch-improvements branch from e4bfc57 to 34c23d0 Compare March 9, 2023 15:27

greg0ire requested a review from mpdude March 21, 2023 19:22

greg0ire mentioned this pull request Mar 22, 2023

Add type declaration to MigrationCollector::reset() doctrine/DoctrineMigrationsBundle#491

Merged

mpdude reviewed Apr 14, 2023

View reviewed changes

greg0ire force-pushed the how-to-choose-a-branch-improvements branch from 34c23d0 to 4c9c51a Compare April 14, 2023 10:13

greg0ire force-pushed the how-to-choose-a-branch-improvements branch from 4c9c51a to f75f309 Compare April 14, 2023 13:25

mpdude reviewed Apr 14, 2023

View reviewed changes

Revamp the contributor guide

7302b61

While some sections feel redundant, other sections were missing, like the one about choosing the right branch.

greg0ire force-pushed the how-to-choose-a-branch-improvements branch from f75f309 to 7302b61 Compare April 14, 2023 13:30

mpdude approved these changes Apr 14, 2023

View reviewed changes

greg0ire merged commit 0c9ba9c into doctrine:master Apr 14, 2023

greg0ire deleted the how-to-choose-a-branch-improvements branch April 14, 2023 13:43


		The general rules are as follows:

		- Patch releases should be as stable as possible. They fix bugs, but in

		3. A window will show up with many lines, remove every line but the last
		ones, which should correspond to your commits.


		Sync your local 2.11.x branch:
		1. Fetch all new commits: `git fetch doctrine``.

Revamp the contributor guide #473

Revamp the contributor guide #473

Conversation

greg0ire commented Jan 24, 2023

SenseException left a comment

Choose a reason for hiding this comment

mpdude commented Jan 24, 2023

greg0ire commented Jan 25, 2023

greg0ire commented Mar 6, 2023

mpdude commented Mar 7, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpdude Mar 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpdude left a comment

Choose a reason for hiding this comment

mpdude commented Mar 9, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

greg0ire Mar 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpdude Mar 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpdude Apr 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpdude commented Mar 9, 2023

greg0ire commented Mar 9, 2023 • edited Loading

mpdude commented Mar 9, 2023

greg0ire commented Apr 13, 2023 • edited Loading

SenseException commented Apr 13, 2023

mpdude Apr 14, 2023 • edited Loading

Choose a reason for hiding this comment

mpdude Apr 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpdude commented Apr 14, 2023

greg0ire commented Apr 14, 2023

mpdude commented Apr 14, 2023 • edited Loading

Choose a reason for hiding this comment

mpdude commented Apr 14, 2023

greg0ire commented Apr 14, 2023

mpdude Mar 9, 2023 •

edited

Loading

greg0ire Mar 9, 2023 •

edited

Loading

mpdude Mar 9, 2023 •

edited

Loading

mpdude Apr 14, 2023 •

edited

Loading

greg0ire commented Mar 9, 2023 •

edited

Loading

greg0ire commented Apr 13, 2023 •

edited

Loading

mpdude Apr 14, 2023 •

edited

Loading

mpdude Apr 14, 2023 •

edited

Loading

mpdude commented Apr 14, 2023 •

edited

Loading