On 18/08/11 10:39, Cor Nouws wrote:
Well I wasn't really trying to answer that question but more give the developer-centric detail about getting a patch into the dev/release branches. But... it f the bug has been fixed, it is fixed right, it has to be marked as such, and in this case approval is asked for the specific release, if approval isn't given then doesn't it sort of make sense that the bug is struck off for that release anyway if we aren't going to fix it?Noel Power wrote (18-08-11 11:16)For example, bug #40079; it is fixed in master, so I closed it. But now it shows up as not blocking "LibreOffice 3.4 most annoying bugs" anymore (it is striked out),when we want a bug to be fixed in the 3.4 release then we need to get the patch into the general dev branch associated with 3.4 ( e.g. the libreoffice-3-4 branch ) and also the release branch e.g. libreoffice-3-4-3. There are rules though about committing to these branches. Currently you need the approval of 1 reviewer to commit to the libreoffice-3-4 branch and the approval of 3 reviewers to commit to the release branch. I have already pushed the patch to 3.4 and//I already asked for a review so that this bug can go into libreoffice-3-4-3. It is a good idea to monitor the mailing list and the information that the patch was pushed to master, 3.4 and request for approval to commit to libreoffice-3-4-3 is all under that same thread you started about the patch for that issue.This explanation still does not cover the case where a bug ís fixed in master, but not in the release A branch, where it is listed as annoying. Having is stricken out, cause of the fix in master, erroneously gives the impression that it is fixed in the release A.x
Noel