Web lists-archives.com

Re: Auto-update for sid? Auto-backport?

On Thu, Nov 16, 2017 at 07:06:39PM +0000, Simon McVittie wrote:
> On Thu, 16 Nov 2017 at 17:02:00 +0000, Holger Levsen wrote:
> > On Thu, Nov 16, 2017 at 05:53:40PM +0100, Wouter Verhelst wrote:
> > > Yes; and semver.org is a formalized system for version numbering stuff.
> > > If upstream has committed to it (and does not make mistakes), then the c
> > > versions in the above example MUST (in the RFC definition of that word)
> > > only contain bugfixes, and no interface changes.
> >  
> > oh shiny! thanks for pointing out semver.org!
> Semantic versioning is not a panacea: it assumes that a developer can
> know in advance whether changes are a compatibility break or not. In
> simple cases where a bug fix or a new feature never causes any unintended
> regressions, that's easy; but if there were no regressions, then we'd
> all run unstable on servers.

There are certainly problems with assigning the correct
semver-compatible version number in some environments, as you point out.
That's also part of why there are multiple revisions of semver itself, I
would assume.

However, those are upstream's problems, not ours; and given that
upstream tries to do the right thing, we can infer from a version number
which changes are expected, and whether it's a good idea.  I could
imagine a policy which would do something along the following lines,
given a X.Y.Z semver-compatible version number:

- if X changes, automatically file a bug but don't do anything
- if Y changes, try to rebuild the package and run any tests (if
  available); post the result to the BTS, but don't upload.
- if Z changes, try to rebuild the package. If autopkgtests exist, run
  them; if they don't fail, upload. If no tests exist, build, but don't
  upload. If uploading, file an "automatic upload happened" bug in the
  BTS, marked release-critical, so that the package won't auto-migrate
  unless someone has at least tested the package in a real-world

There will still be risks; there are always risks. In this context, and
with that policy, however, I think that they are minimized and

(I could imagine that if the package was involved in a transition, the
release managers would also not like it if the package was
auto-uploaded; having the script that implements the above look at the
transitions configuration before trying any upload might be helpful to
avoid that)

Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008