> Markus Mohrhard wrote >> * Does the fix contain a new feature? >> * How important is the bug fix? >> * Is the fix safe enough for a stable branch? >> * How much did the code change between the two versions? > > Points 1 and 2: if it's a regression it's not new and it's EXTREMELY > important not to have regressions (regardless of importance of the feature)
No. Just because it is a regression does not mean that it is that important that we will included it without a careful risk analysis. > Point 3: that is why it needs to be checked by 3 devs In the first place it is the task of the author/commiter to decide if it is safe enough in his opinion. If he does not feel comfortable with a patch in a stable branch there will not be a review by 3 other developers. The author/commiter is normally the person knowing the code best. > Point 4: that should not be relevant. If the regression is already fixed in > master, then it should not be that difficult to backport it to the current > branch (unless it's a major version change) We have about 70 to 100 commits per day and you would be surprised how different master and 4-1 are already in quite a few places. I already had the nice experience for this release that my fix from master did not work any more in 4-1 because the whole Calc logic changed in the few weeks since the rebase. In the end every change, even a simple bug fix, has the risk of introducing another regression so there will never be an automatic process for pushing fixes to a stable branch. Every commit has to be checked against these points to decide whether it is worth the risk to include the fix into the stable branch and after that and totally independent from it is the actual review by other developers of the code. > > > Markus Mohrhard wrote >> This should never be an automatic process, instead each commit needs this >> check by >> a developer. > > I agree completely. I never mentioned automatic. But it should be included > in the list of checks before a new release to make sure that ALL MAB > regressions that *were* fixed should be cherry picked to the nearest > release. I believe that is the reason there are 2 Release Candidates before > the final release... For me automatic in this context means that a bug fix has to be pushed after review despite concerns of the author/commiter. Fixing bugs comes with risk management and that means to compare the benefit of fixing a bug and the risk of introducing another regression. For every bug this depends very much on how serious the bug is and how complex the bug fix is. Additionally bug fixes that require translatable string changes or implementing a new feature have stricter rules and have an even more complex review process. And saying that a bug deserves special treatment because it is on a special list is quite dangerous. The MAB list should only be used to notify developers about serious bugs but should not influence the risk analysis. Surely if the bug is on the MAB it is important but that is just one aspect of the risk analysis. This still means that all the other aspects have to be checked before the bug can be pushed to a stable branch. I think that we are doing a quite good job at reviewing bug fixes for stable branches but some commits are just too risky or too complex for this. Regards, Markus _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/