Re: Build split and raising/verifying issues

[Graham Percival]

On Sun, Apr 17, 2011 at 01:32:59PM +0100, Phil Holmes wrote:
> I'm reasonably confused about the ramifications of the split to 2.13
> and 2.14.  Will there be release versions of 2.14, which will
> require testing? What needs to be done in terms of regtest checking
> for builds? 

As far as you need to know, there are simply 2.13.x releases.  If
there is any bug marked with "fixed_2_13_x", then you verify it
using GUB 2.13.x or later.  You will be seeing a lot of bugs
marked "fixed_2_15_0".  Since you do not have a GUB build with
that version number (or later), do not attempt to verify them.

Regtest checking is completely unchanged, other than being more
important than ever.  Whenever there is a new release, look at the
regtest comparison and raise a fuss about any bad changes.

> What will constitute a critical bug,

Completely unchanged: any segfault or regression in a 2.13.x
release since 2.10.33.  As before, a programmer may argue that
something is not an important regression (mainly because the
earlier behavior was not intentional), and the initial bug report
may have its priority downgraded.

But that's a concern for developers, not the bug squad.

> and do we need
> specific labels to identify which build the bug applies to?

There is nothing for which the phrase "which build" makes sense.
There are GUB releases with version numbers 2.13.x.  That is all.

> Are there any changes to the verification process?

No.

> And while I'm at it - we're now raising issues to track patches, but
> these frequently have no sample code to use to verify.  Do we need
> to do anything wrt verifying these where they're claimed fixed?

Check if you see that patch in git.  Often we give a commit hash,
so if you see "pushed 1234abcd" in the issue tracker, but you do
not have a commit number 1234abcd in your own git, then something
is wrong.  If there is no "pushed 1234abcd" message, then check
for a subject message in git, and maybe complain about whoever
marked it "fixed" without giving a git commit number.

Cheers,
- Graham