Hi Simon,
On Thu, Jul 05, 2018 at 11:15:08PM -0500, Simon Quigley wrote:
> This email is following several discussions I have had over the past few
> weeks on how the versioning scheme of packages work with respect to
> stable releases.
Thank you for bringing this up.
Right now, though I prefer the security team's documented scheme, I
understand that this isn't fixed by any policy so I usually reluctantly
accept other schemes from uploaders unless I think there is some
specific issue with it.
However, I would like to see our project having more consistency on this
in the long term.
For example, onboarding new developers (whether colleagues of mine at
Canonical or other volunteers) is made more difficult for everyone if
things aren't consistent, because astute propsective developers should
be asking about inconsistencies and this wastes everyone's time. And
it's also painful to be a prospective developer if you repeat patterns
you see elsewhere but don't know what your sponsors will or won't
accept, and what the SRU team will or won't accept.
To this end, I'd like to see SRU policy move from "this team does it
well; you may want to do it like them" to "this is our recommendation"
to "this is a requirement and results in a reject unless you can justify
an exception".
However, I'm not sure we're ready to move hard on that yet. I'd like to
see better tooling first, so any change creates less friction in the
short term. I have plans about this.
In git ubuntu, we have the beginnings of a "lint" tool. I haven't worked
on it in a while and it needs major refactoring before continuing. I
don't recommend it for general use yet. But eventually I want to be able
to recommend it for use by uploaders and sponsorees, as well as have it
run in CI against the sponsorship queue (which I hope will use a
MP-based workflow by then).
Then I'd like the lint tool to simply be able to say "I was expecting
version string X for this that appears to be an SRU, but I see version
string Y instead".
At this stage I expect that I'll want to push for this kind of
consistency to become a recommendation and hopefully eventually policy
(except for edge cases and where an exception is justified).
This is my general answer for matters of upload consistency FWIW. I want
to get the lint tool to the stage that it is reasonably pluggable,
implement a check for any perceived inconsistency as a warning in the
tool, and then move towards recommendations and policy from there.
I'm not sure I'm in favour of policy changes in this consistency area
until we have the tooling, as I'm concerned it'll cause too much
friction in existing workflows (especially in the very long
upload/reject review cycle for SRUs we have at the moment). With the
tooling, I'm hoping to be able to close the reject delay by
short-circuiting it.
> With ubuntu-report, I have always been discouraged from using codenames
> in the version number, because if, for some reason, we needed this in
> Xenial, being consistent with the naming scheme wouldn't work:
>
> $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~xenial"; echo $?
> 1
> $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $?
> 0
>
> This means we would have to be inconsistent across releases.
I'm in favour of implementing a general and immediate ban on using
release codenames in version strings to prevent confusion. AFAIK,
release numbers can always be used in their place, and the pattern is so
rare (I didn't even know it was still done in the archive) that I think
it'd cause almost no pain to implement. It's a dangerous pattern because
it sets up an expectation that doesn't always hold, as you point out. I
think it's worth breaking the pattern in any package that already uses
it.
> With shim, I have also been discouraged from doing ubuntuX, as opposed
> to ubuntuX.Y. In this case, I would have gone with 13-0ubuntu0.2.
I prefer ubuntuX.Y instead of ubuntu(X+1) for SRUs as I think it's
helpful to make it obvious that it's an SRU and it avoids the necessity
to check that ubuntu(X+1) isn't already in use (which is error prone).
However I continue to reluctantly accept ubuntu(X+1) because it's a
pattern that so many developers seem to use. This is one that I want to
resolve in the long term by encouraging via a lint tool first before
turning it into a recommendation and eventually policy.
> Is the existing document by the Security Team[1] lacking any important
> considerations? Can we adopt it as the uniform standard for updates in a
> stable release, or is there a good reason to continue with inconsistency
> here?
I'm in favour of turning it into a recommendation today. I thought it
already was, but I understand that some don't read the existing
documentation that way.
I don't want to mandate it until much further down the road though.
Robie
