Hi all,<div><br><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(80, 0, 80); font-family: arial, sans-serif; font-size: 13px; ">> I think you skipped over the most important point in fuzzie's questions:<br>
> How do we handle bugs which get "quick fixes" on the release branch,<br>> and more thorough fixes on "trunk".  Do we immediately merge the quick<br>> fix and then revert it ("reverse cherry-picking") before making the<br>
> thorough fix, or do we make the fixes in parallel and get a conflict<br>> when later merging the quick fix (or worse, _not_ getting a conflict<br>> and potentially have two fixes for the same thing)?</span><br>
<br></div><div>If I'm thinking straight, this is solved by usual rebase and merge. I suppose a quick fix is done because there's no time for a good fix before the release because if there was time enough the thorough fix would be used instead.</div>
<div><br></div><div>We have our development branch ("master") and we prepare for a release (simply stating our code is mature), so we branch "stable". A bug is found in "stable", so we branch for bugfix or apply directly a bugfix (quick or not). At the same time we are working in new stuff on "master" _but_not_ bugfixing "master". Now we rebase "stable" changes onto "master", so the quick fix is applied to "master" and a thorough fix can be applied later, without reverting the quick fix, simply a modifying commit.</div>
<div><br></div><div>When the time comes we tag our "stable" branch, rebase onto "master" whatever wasn't rebased yet and continue working in "master".</div><div>Time for another release! Straight-forward merge from "master" to "stable", "stable" branches out and repeat.</div>
<div><br></div><div>The most important part is to bugfix only in "stable" (except if the bug is only present on "master"). This prevents cherry-picking, history is consistent and most merges are straight-forward and clean.</div>
<div><br></div><div>My 2 cents,</div><div>Miguel</div><div><br><div class="gmail_quote">2011/5/31 Marcus Comstedt <span dir="ltr"><<a href="mailto:marcus@mc.pp.se">marcus@mc.pp.se</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Max Horn <<a href="mailto:max@quendi.de">max@quendi.de</a>> writes:<br>
<br>
</div><div class="im">> Well, they do have releases every couple weeks or so. It's hard to imagine that they never find a bug in 1.x.y.z that ought to be fixed in 1.x.y.(z+1), right away, but for which a "proper" fix requires a  substantial change that is not desirable for that. But maybe that just never happens to them due to incredible luck / planning. Or do they simply refuse to fix urgent data loss bugs as long as no "proper" solution can be implemented, even if a hotfix is known?<br>

<br>
</div>The tendency seems to be to refuse bugfixes unless they restructure<br>
the whole code according to Junio's visions of how the bug _should_ be<br>
fixed, yes.  The case I was involved with was a bug in ident handling<br>
which caused data loss.  Of course, Junio doesn't use ident, so it<br>
wasn't urgent to _him_...<br>
<font color="#888888"><br>
<br>
  // Marcus<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Simplify data backup and recovery for your virtual environment with vRanger.<br>
Installation's a snap, and flexible recovery options mean your data is safe,<br>
secure and there when you need it. Data protection magic?<br>
Nope - It's vRanger. Get your free trial download today.<br>
<a href="http://p.sf.net/sfu/quest-sfdev2dev" target="_blank">http://p.sf.net/sfu/quest-sfdev2dev</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</div></div></blockquote></div><br></div></div>