[Libreoffice-qa] URGENT Cherry pick regressions to next release

[Markus Mohrhard]

> 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