Documentation: Remove paragraph *Decide what to base your work on.*

This paragraph doesn’t apply to us, so remove it.

Documenation/SubmittingPatches

@@ -1,39 +1,6 @@
 Here are some guidelines for people who want to contribute their code
 to this software.
 
-(0) Decide what to base your work on.
-
-In general, always base your work on the oldest branch that your
-change is relevant to.
-
- - A bugfix should be based on 'maint' in general. If the bug is not
-   present in 'maint', base it on 'master'. For a bug that's not yet
-   in 'master', find the topic that introduces the regression, and
-   base your work on the tip of the topic.
-
- - A new feature should be based on 'master' in general. If the new
-   feature depends on a topic that is in 'pu', but not in 'master',
-   base your work on the tip of that topic.
-
- - Corrections and enhancements to a topic not yet in 'master' should
-   be based on the tip of that topic. If the topic has not been merged
-   to 'next', it's alright to add a note to squash minor corrections
-   into the series.
-
- - In the exceptional case that a new feature depends on several topics
-   not in 'master', start working on 'next' or 'pu' privately and send
-   out patches for discussion. Before the final merge, you may have to
-   wait until some of the dependent topics graduate to 'master', and
-   rebase your work.
-
- - Some parts of the system have dedicated maintainers with their own
-   repositories (see the section "Subsystems" below).  Changes to
-   these parts should be based on their trees.
-
-To find the tip of a topic branch, run "git log --first-parent
-master..pu" and look for the merge commit. The second parent of this
-commit is the tip of the topic branch.
-
 (1) Make separate commits for logically separate changes.
 
 Unless your patch is really trivial, you should not be sending