Hi Steve,
On Thu, Apr 20, 2017 at 04:46:23PM -0700, Steve Langasek wrote:
> On Thu, Apr 20, 2017 at 01:36:26PM +0100, Robie Basak wrote:
> > 1) What package name and version string was tested (saying "the one from
> > xenial-proposed" isn't enough for me, as this is where we see things
> > going wrong as that version can change).
> FTR I do consider your point 1) to be a policy change, and not one I'm
> sanguine about. We struggle to get SRUs through the verification process
> today, and I don't think raising further barriers significantly improves the
> outcomes for our users but /would/ slow things down by requiring further
> round trips.
I always assumed that "If this package fixes the bug for you, please
add a comment to this bug, mentioning the version of the package you
tested..." meant that one can expect the version string to be explicitly
present in a verification comment compliant with this request. Do you
disagree, or do you not consider the templated request to be de-facto
policy?
I agree that we should not be raising any further barriers. My goal here
is also to reduce round trips and related SRU friction.
Right now when I review bugs showing as green in the pending-sru report,
I find myself spending time trawling through the comments to figure out
what was verified, since from recent experience the tag doesn't give me
sufficient confidence. I'd be able to get through releasing SRUs quicker
if it were called out explicitly.
If someone is actually verifying the bug and reporting the verification,
how onerous is it really to ask that the package version tested be
explicitly reported? The version string should normally be right in
front of the verifier and trivial to copy and paste (in the common case).
If it isn't explicit and I am not sure, then it is _this_ that creates
an extra round trip currently, for me anyway, when I ask for
clarification. If we had consensus that reporting the version string was
the right thing to do, and it was documented correctly everywhere, then
I am hoping that these extra round trips will no longer be necessary.
I could even write a bot that flips back the tag with an explanation and
a request for clarification if the expected package version string
hasn't appeared in a comment. This would eliminate the necessity for a
human round trip entirely. I'm not sure it's the right thing to do, but
I hope it illustrates my point.
As an aside, I've been considering doing the same with dep8 failures -
automatically ask the SRU driver to investigate and report ("not
relevant to this SRU because <reasons>" would be a fine response), thus
saving ~ubuntu-sru time, and hopefully without any need for an
additional ~ubuntu-sru round trip since a bot would mention it as soon
as the information is available.
> You are of course right that we need to have confidence the package which
> was tested is the actual package which will be released. But I don't think
> that means we should have a hard rule that an SRU verification comment needs
> to list the version number, because while the version in -proposed can
> change over time, in most cases it's *not* ambiguous which version was in
> -proposed when the user tested.
>
> What do you think about a wording such as this?:
>
> - The SRU verification must clearly indicate which package was tested.
> The most reliable way to ensure this is to list the version number of
> the tested package.
I don't object to the wording, but I question whether it really is so
onerous to simply require it.
Robie
