[Libreoffice-qa] Bugzila 4.3.x versions cleanup

Joel Madero jmadero.dev at gmail.com
Tue Dec 1 08:42:51 PST 2015

On 12/01/2015 02:59 AM, Pedro wrote:
> Hi Joel
> jmadero wrote
>>> If a user is able to tell that a bug was introduced between 4.0.0 and
>>> 4.0.1,
>>> a bibisect in that range should be able to find the problematic
>>> commit/patch?
>>> What would be the advantage to have the user install 4.0.0 Beta1, Beta2,
>>> RC1, etc?
>> Bibisect is really only at this point useful for Linux because the
>> documentation on OSX and Windows is still below par. That's at least my
>> understanding - have you tried to bibisect on other platforms?
> No, I never tried bibisect on Windows. But Sophie volunteered to give me a
> hand if I decided to try so I assume it is possible.
> Again, what would be the advantage to have the user install 4.0.0 Beta1,
> Beta2, RC1, etc? Reducing the search range to a 0.0.1 isn't good enough?
> Does the full footwork have to be on the QA side?
The benefit is narrowing it down by hundreds of commits....have you ever
looked at how many commits are between two alphas? Or between two point
releases? If we're sitting here screaming and yelling about regressions,
the more we narrow down the more likely regressions will be dealt with.

Example (commits between...): beta1 and release: 357 and beta2: 42

As far as "all the footwork be on QA side" - yes.....because all the
development work is on the developer side (it's not like they are asking
us to code.....). It's our job to narrow down the issue as much as
possible (down to a single commit is best obviously) and then developers
can take over and do their magic with the code (that is almost always
way above my head).

This debate is going in circles - if no one else agrees with me then go
ahead (Tommy has permissions), just make sure to document it somewhere.
I'd give it a couple more weeks to see if someone else has additional
thoughts. My thought is that if a user is so super confused based on a
few extra versions then....well then there bug reports are likely to be
bad anyways (it's not a high bar to understand versions).

@Tommy - I suggest clarifying what the proposal is at this time as you
and Pedro have deviated substantially.


More information about the Libreoffice-qa mailing list