FixesOnMaster

Bug Fixes done directly on the master

The Reality has shown, that the child workspaces do not fix all issue in advance before the integration of child workspaces into the master. There are several reasons for doing fixes on the master:

BugFixes by RE on master

• Merge Conflicts: Even though child workspaces are synchronized with a recent milestone, there is still the chance of getting merge conflict when integrating child workspaces on the master. Since the Integration of child workspaces are done by Release Engineering (RE) a Release Engineer is able to resolve the conflict and commit directly to the master workspace.

• Syntax Errors: Child workspaces are already tested with several compiler versions and platforms, but since it can't be required to compile on all platforms and configutation the chance of a remaining syntax error

• Packaging Errors: not all of the product variants are tested on cws.

• Other errors not detected on child workspace:
  • P1 - Issues
    • forgotten to commit files on cws
    • not included in automated test scenario
    • not included in regression tests

Tracking fixes on master

Commits to the master are done with mws_commit to enable tracking commit on the Master via EIS.

Proposal for doing regular commits on the master

The experiences from the old development model (direct commits to the release/development branch have shown that developing new features and doing bug fixes on branches is a good thing and gives the participating parties (Dev, QA, UX) the freedom and safety to try and test out new code without disturbing other teams. Despite these facts there are some cases, in which commit to the master are more efficient than dealing with a cws:

• fix build breakages also outside Hamburg RE: build around the clock: if build breakages occur, a developer should be a fix such breakage via mws_commit, the mws_commit should be able the various build machines and systems to restart their builds. This allows fixing build breakages also out Hamburg business hour.

• some of the P1 fixes:
  • critical to get into the current milestone
  • hinders the bootstrapping of tools used in the build
  • component not registered during build
  • confirmed by reviewer that fix is obvious and trivial

• build system fixes
  • if build breaks on platform
  • build tools, not used in the standard build process, e.g. patch systems used as add on to vanilla build systems
  • helper tools outside of the vanilla build system

• documentation (such as license headers, build documentation, readme, license files, comments in source files etc) are sometimes time critical to update. In case of just doing modifications or additions a mws_commit should be possible (with review).

• trivial fixes: by default, trivial fixes are done in cws. after review (<reviewers list and criteria needed!>) such fixes are allowed if now appropriate cws is available or fix is time critical.
  • unproblematic warning fixes (e.g. uninitialized variables, typos, accelerators in resource files, missing new line, EOF, missing parameter )
  • can be done with an atomic commit (only one file change)