[Libreoffice-qa] After EOL has been reached...

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Fri Apr 26 09:36:39 PDT 2013


On Fri, Apr 26, 2013 at 11:26:33AM -0400, Robinson Tryon wrote:
> On Fri, Apr 26, 2013 at 11:08 AM, Bjoern Michaelsen
> <bjoern.michaelsen at canonical.com> wrote:
> > On Fri, Apr 26, 2013 at 10:56:21AM -0400, Robinson Tryon wrote:
> >> This kind of scenario is one of the reasons I was interested in
> >> implementing my "Repro Table". The current version drop-down is both
> >> too long and not granular enough to visually indicate the NOREPRO in
> >> 3.6.2 rc1 and the REPRO in 3.6.2 release. The Repro Table could
> >> display that information very clearly, but I am digressing a bit :-)
> >
> > But we dont really need a table, but only the first version the bug reproduces
> > (and possibly the last version that does not reproduce it), right?
> For most cases, yes, we would just need 2 versions (and notes on each
> OS used for repro), but... there are special cases :-)
> 1. Platform-specific bugs
> If a bug is platform-specific, then the table can help to show that.
> It could also show the case (which many agree would be very rare) of a
> bug that might affect just Mac/Linux and not Windows.
> 2. Fixed and then reappearing
> Joel made a note that some bugs might be fixed and then reappear in a
> later build. He was specifically talking about issues when
> bibisecting, but it could just as easily appear in testing with other
> builds.

So, as a developer, I would think comments (and the platform field) would be
sufficient for these rare cornercases. For fixed and reappearing, I think its
not really an issue:
- if the bug is really fixed, it should have a dev having insight in the some
  issue already (and reading a few comments is not so much work compared to the
  total effort in these cornercases)
- if the bug was not fixed but just "disappeared" -- that is, stopped being
  there without a dev claiming to intentionally having fixed it, it is likely a
  Heisenburg anyway and the version info to be used carefully (or even ignored)



More information about the Libreoffice-qa mailing list