<div dir="ltr">Totally! Now I got it. <br><br>Thank you very much.</div><div class="gmail_extra"><br clear="all"><div>Um abraço,<br>Tiago Porangaba</div>
<br><br><div class="gmail_quote">On Tue, May 21, 2013 at 5:31 AM, Robie Basak <span dir="ltr"><<a href="mailto:robie.basak@canonical.com" target="_blank">robie.basak@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, May 18, 2013 at 12:37:04AM -0300, Tiago Porangaba wrote:<br>
> However I am not sure what you mean saying *"isolating and*<br>
> *cherry-picking fixes shouldn't be too difficult."*<br>
> *<br>
> *<br>
<div class="im">> My guess is that you mean that I should pick a triaged bug, pick one fix<br>
> from some suggested fixes and submit this fix (after QA). Is that right?<br>
<br>
</div>The SRU process requires that we fix the development version first. This<br>
is often achieved by taking the latest upstream version that might<br>
already have the problem fixed, or applying our own fix.<br>
<br>
Then we have to backport the fix to stable releases for bugs where we<br>
feel it is appropriate. You can find a list of such bugs at [1] that<br>
have been nominated for (Precise) 12.04, for example. To prepare the<br>
fix, I'm proposing that as a programmer you may be able to more easily<br>
locate the patch that fixed the problem in the development version,<br>
backport it (change it as needed so that it applies correctly to the<br>
older version and still fixes the problem), make it minimal if necessary<br>
(so that it's easier to understand and minimises the chances of<br>
regressions), test it, and prepare a debdiff for an update to the stable<br>
release.<br>
<br>
Does that make sense?<br>
<span class="HOEnZb"><font color="#888888"><br>
Robie<br>
</font></span></blockquote></div><br></div>