Voting/Miscelanea branches

From ReactOS Wiki
Revision as of 15:10, 19 March 2005 by 68.39.174.205 (talk) (Moved from the old page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

  • arty
  • royce3
  • ion

3 votes

Points:

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

No, don't allow miscelanea branches

  • navaraf
  • gvg
  • hbirr
  • w3seek
  • gdalnes
  • ea
  • chorns
  • mf (Martin)

7 votes

Points:

  • 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.

[1]

  • 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.