From b586e8ac232a3dea1e1abcd62cae72b26072a061 Mon Sep 17 00:00:00 2001 From: Paul Menzel Date: Wed, 23 Nov 2016 11:20:27 +0100 Subject: [PATCH] Documentation: Remove paragraph *Decide what to base your work on.* MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This paragraph doesn’t apply to us, so remove it. --- Documenation/SubmittingPatches | 33 --------------------------------- 1 file changed, 33 deletions(-) diff --git a/Documenation/SubmittingPatches b/Documenation/SubmittingPatches index fb61e3459..69885ae7c 100644 --- a/Documenation/SubmittingPatches +++ b/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