[Bf-committers] Committing fixes for releases in stabilizing branch.

[Campbell Barton]

This change in branch usage doesn't cover...

- How to handle fixes that are first made to master,
  and later on we find should be applies to the stable branch
  (merge? cherry pick?).

- How to handle fixes that backfire
  (eg, a fix we make in the stable branch, then cause issues,
  then we want to remove from the stable branch but keep in master).

- How strict are we on merging immediately after committing
  to the
stable branch?

  So far there has been some accumulation of multiple commits
  to the stable branch which then get merged.

  Is it discouraged to push multiple fix commits,
  then a merge afterwards?

Also, it would be good if there was some context around why changes
like this are made.

On Thu, 2019-10-10 at 10:34 +0300, Nathan 'jesterKing' Letwory wrote:
> Hey all,
> 
> Soon the stabilizing branches will be created. While not much will
> change, but there are a couple of things to keep in mind.
> 
> Any bug fix planned for the upcoming release should go to the
> corresponding branch (e.g. `blender-v2.81-release`), followed by a
> merge to `master`.
> 
> Take your time to verify your fixes are correct and the commits look
> good (as per usual).
> 
> More detailed guidelines can be found on the wiki at:
> https://wiki.blender.org/wiki/Process/Using_Stabilizing_Branch
> 
> There will be a message to this list once the stabilizing branches
> have been created.
> 
> Cheers,
> 
> /Nathan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers