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).
On Thu, Apr 20, 2017 at 02:39:07PM +0100, Robie Basak wrote:
> On Thu, Apr 20, 2017 at 03:28:39PM +0200, Sebastien Bacher wrote:
> > requirement ... and indeed it's not in the wiki. So we have at least one
> > example where something checked the wiki documentation as a reference,
> > wiki also is easy enough to edit so there is no real reason to not do it.
> Thanks. I don't think I'm actually suggesting any change in policy here
> - it seems to me that what I'm asking for isn't consistently written
> everywhere even though it is actually current policy (because it has
> always* been asked for in at least one place). So I'll JFDI and edit
> everything for clarity, including the wiki, unless someone objects.
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
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.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/