[Scummvm-devel] Towards a new release branch model

[Tarek Soliman]

On Wed, Jun 01, 2011 at 02:24:52PM +0200, Marcus Comstedt wrote:
> 
> Tarek Soliman <tarek-spam at zeusmail.bounceme.net> writes:
> 
> > But consider the situation where the quick fix is to add a workarounds entry to sci and the real fix to make a script patch.
> > The same commit for the script patch would be taking out the workarounds entry. That's what I meant by not needing an explicit revert commit.
> 
> That assumes that the quick fix is merged before the real fix is
> done.  Note that the quick fix and the real fix may be available at
> the same time, but the real fix introduces a greater risk of
> unexpected regressions, and therefore requires more testing time than
> what is available before the release.  The method could still work if
> you are required to merge the quick fix to master before making the
> real fix, meaning multiple merges instead of one big merge after the
> release drop.  But you must always have the quick fix ready for commit
> before you can commit the real fix, or this method will not work.

This is an excellent point. I didn't think of that.
That's one situation where you may have to explicitly revert.

Is the workflow supposed to be hard rules or just guidelines "use your judgement" kind of a thing? Kind of like rebase vs merge when you get a push-rejection.
I am almost sure there is no single workflow that can cover every situation with no disadvantages.
-- 
Tarek