Dear wiki user,

You have subscribed to a wiki page "Couchdb Wiki" for change notification.

The page "Merge_Procedure" has been deleted by JoanTouzet:

https://wiki.apache.org/couchdb/Merge_Procedure?action=diff&rev1=17&rev2=18

Comment:
We moved to a RTC model with master always releasable, in theory.

- ## page was renamed from Merge_procedure
- <<Include(EditTheWiki)>>
  
- = Introduction =
- 
- A typical timeline might look like this:
- 
-  * Release 1.3 (June)
-  * Create the 1.4.x release branch (June)
-  * Merge feature A in to 1.4.x branch
-  * Merge feature B in to 1.4.x branch
-  * Merge feature C in to 1.4.x branch
-  * Release 1.4
-  * Create 1.5.x release branch
-  * Merge bugfix 1 in to 1.4.x branch
-  * Merge bugfix 2 in to 1.4.x branch
-  * Merge bugfix 3 in to 1.4.x branch
-  * Release 1.4.1
- 
- Each one of these items is the responsibility of the Release Manager.
- 
- The developers submit merge requests for completed work to the Release 
Manager.
- 
- The Release Manager should follow this document when handling merge requests.
- 
- Nothing should be committed to a release branch besides what goes through 
this process.
- 
- If we all follow this, it will improve our code quality, test coverage, and 
documentation.
- 
- = Feature Branches =
- 
- Most work should happen in feature branches.
- 
- If there is not already a ticket for your work, 
please[[https://issues.apache.org/jira/browse/COUCHDB | create one]].
- 
- == Naming ==
- 
- Please use the ticket number, the type of the branch, along with a very short 
descriptive phrase, for your branch name.
- 
- If the ticket was COUCHDB-1234, and the ticket title was My Cool Feature, 
your branch should be called `1234-feature-cool`. If the issue is a bug and the 
branch includes the bug fix, it should be called `1234-fix-cool`. If `cool` are 
multiple words, separate them with a dash: `1234-feature-cool-stuff`.
- 
- == Git Best Practice ==
- 
- Developers are free to use a feature branch in any way they see fit during 
development. Prior to submitting a merge request to dev@, though, the branch 
should be prepared according to the following rules, as the commits on the 
feature branch will be a permanent part of the couchdb project's history.
- 
- A feature branch should consist of the smallest number of meaningful commits 
as possible. For bug fixes and small features, this is likely to be a single 
commit. For larger changes, multiple commits might be necessary. The guiding 
principle for deciding how many commits is coherence. A commit should be 
readable and, ideally, implement one distinct idea. A feature that requires 
multiple enhancements to achieve its goal should be presented as multiple 
commits. It is *not* necessary for the system to pass the test suite for any 
subset of these commits, only their combination.
- 
- = Merge Request =
- 
- The merge request is done by the developer wanting to add changes to a 
release branch.
- 
- If you want to make a merge request, please follow these steps:
- 
-  * Prepare your code on a feature/bugfix branch.
- 
-  * Add any new tests that cover your code.
- 
-  * Add any new docs that cover your code.
- 
-  * Run `make distcheck` a few times and verify that it works reliably.
- 
-  * Send an email to 
[[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing 
list. [[http://wiki.apache.org/couchdb/Merge_Request#preview | You can use this 
template]]. ''@@ Create template in couchdb-admin''
- 
-    * Choose a subject like "[MERGE] Feature description"
- 
-    * Have you added tests? If not, explain why.
- 
-    * Have you added docs? If not, explain why.
- 
-    * Does `make distcheck` work reliably? If not, start over.
- 
-    * Ask people to check your code.
- 
-  * Wait 72 hours for a lazy consensus.
- 
-    * And then nudge a Release Manager if necessary!
- 
- = Merge Testing =
- 
- If someone has posted a merge request to the mailing list, you should test it.
- 
- Here are some things you can do:
- 
-  * Are there any tests?
- 
-    * If not, are you happy with the rationale provided?
- 
-    * Are the tests good tests?
- 
-    * Do the tests cover the code properly?
- 
-    * Are the tests reliable?
- 
-      * Do they fail on slower systems?
- 
-      * Do they fail indeterminately?
- 
-  * Are there any docs?
- 
-    * If not, are you happy with the rationale provided?
- 
-    * Are the docs good docs?
- 
-    * Do the docs cover the code properly?
- 
-    * Are the docs easy to understand?
- 
-  * Does `make distcheck` work reliably?
- 
-  * Does the code run on multiple operating systems?
- 
-    * Can you test it under Linux?
- 
-      * Can you test it under multiple distributions?
- 
-    * Can you test it under OS X?
- 
-    * Can you test it under Windows?
- 
-  * Can you test it on multiple architectures?
- 
-    * Can you test it under 32 bit?
- 
-    * Can you test it under 64 bit?
- 
-  * Can you test it on multiple interpreters?
- 
-    * Can you test it on the latest Erlang?
- 
-    * Can you test it on the stock Erlang?
- 
-    * Can you test it on other version of Erlang?
- 
- Please look in to as much of this as possible, then send your results back to 
the list.
- 
- Hopefully, we can automate some of this testing at some point soon.
- 
- Do you fancy helping us with that? 
[[http://couchdb.apache.org/#contribute|Get in touch!]]
- 
- = Merging =
- 
- An actual merge should only be done by the active Release Manager.
- 
- Once a merge request has been tested by the community, and you are happy, you 
can proceed.
- 
- == Feature ==
- 
- Follow these instructions to merge a feature in to one release branch.
- 
- Feature branches are merged to release branches using 'git merge --no-ff 
<FEATURE BRANCH>'. This guarantees a merge commit, which are the only kinds of 
commit that will appear on release branches. If the merge results in conflicts, 
the release manager rejects the merge commit with an reply to the dev@ thread. 
If the merge is successful, the release manager should run 'make distcheck' and 
push the merge upstream if the tests pass. 
- 
- == Bugfix ==
- 
- Follow these instructions to merge a bugfix in to multiple release branches.
- 
- For each release branch, 'git checkout <RELEASE BRANCH>' and 'git merge 
--no-ff <BUGFIX BRANCH>'. If any of the merges fail, the merge request is 
rejected.
- 
- == Security ==
- 
- Follow these instructions to generate a patch for unsupported releases.
- 
- (Security fixes can be merged in to supported release branches just like 
bugfixes.)
- 

Reply via email to