Voting/Miscelanea branches

From ReactOS Wiki
Revision as of 17:09, 25 April 2005 by Chorns (talk | contribs) (What this page is for)
Jump to: navigation, search

What is a "Miscelanea branch"?

Please could someone put a paragraph or more in here to explain what this is? It might be useful to open up the vote to more people who may want to help develop ReactOS in the near future but who are not up to speed on the lingo. Cheers, --Rebroad 18:52, 31 Mar 2005 (CEST)

First read below. If that is not enough, then please ask about something more concrete that you want explained. Voting is currently only of interrest to committers though since only they are allowed to vote (it's not hard to get commit access though). Also, this area of the wiki is only for tracking past votes. The actual voting takes place on the ros-dev mailing list. --Casper Hornstrup.

Mailing list thread

Should we allow branches (other than trunk) with mixed new development and bugfixes unrelated to the new development that is on the branch (miscelanea branches) ?

Yes, do allow miscelanea branches

3 votes


  • You can have a version control enabled private space where you can work and not disturb other developers.

No, don't allow miscelanea branches

7 votes


  • It's nearly impossible to keep track of all changes happening on miscelanea branches. When one commits 15 files in EX/, 17 files in IO/ and bunch of other stuff with changelog message "My kernel fixes, new apis, reformatting, commenting, documenting, reorganizing, bug fixing, optimizing patch." it's just impossible to review. Especially mixing reformating patches with other changes makes reviewing much harder...
  • When one tries to boot ReactOS of a miscelanea branch and it doesn't work for him there's (almost) no way to track it down. One has to use conventional debugging methods. For feature branches[1] one at least knows where to start looking at and it's often possible to pinpoint the problems by just looking at the .diffs.
  • Merging miscelanea branches at one time to trunk causes only chaos. If a miscelanea branch has modification to all components ranging from win32k, kernel, TCP/IP to UM kernel32 changes. Would you really want to merge the 800Kb diff at once?
  • Bugs that that could have been fixed on trunk are annoying to trunk developers. The bugfixes that go only to the branch are not in trunk (until merged there from the branch) where most developers work and is thus annoying to these developers.
  • There is an added risk of duplicating work. We'll have more branches to track bugfixes on so it's harder to know which bugs has been fixed and which hasn't.
  • One can usually avoid using miscelanea branches by using more feature branches which can be merged to trunk earlier (which is especially important for bugfixes).
  • To get what is demanded by "You can have a version control enabled private space where you can work and not disturb other developers" you can install and use SVK to version control your local changes. Later on you can merge back your bug fixes and ready new features to the main repository. Using SVK it's even possible to sync the latest trunk changes into the local SVK repository.


  • Release branch. Usually created some time before a release to have a more stable product at the time of a release. Only bugfixes go to this branch.
  • Feature branch. Usually created to achieve a well-defined purpose (e.g. the implementation of a new feature). Only changes required to achieve the well-defined purpose are committed to this branch.
  • Miscelanea branch. A combination of release and feature branches.