On Wed, Apr 10, 2019 at 04:27:09AM +0200, Matthias Klose wrote:
> >> Regarding rails I agree with dropping it from Disco, but this is more
> >> of a call for help to get it in again in Disco+1 if there is a strong
> >> community around it rather than discouraging people from maintaining
> >> language stacks in Ubuntu or Debian.
> > Agreed! The intention here is absolutely not to say that rails can't be
> > part of Ubuntu, but to say that rails in its present state is not a net
> > benefit to our users.
> In the meantime somebody apparently did remove the packages with failing
> autopkg tests which were already removed in Debian. That's a good thing,
> however it has kind of a smell if this only happens after such
Well, I mentioned in my mail that I was doing this - as I do usually about
once a month throughout the cycle. The particular removals from Debian
happened about a month ago. So this is not a major factor either way in the
releasability of rails over the past 12 months.
> Now the situation is:
> rails (2:4.2.10-0ubuntu4 to 2:5.2.2+dfsg-6ubuntu1)
> Invalidated by dependency
> Depends: rails puma (not considered)
> puma (- to 3.12.0-2)
> 58 days old
> autopkgtest for puma/3.12.0-2: amd64: Regression ♻ , arm64: Regression ♻ ,
> armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ ,
> s390x: Regression ♻
> rails is ready to migrate, there is no puma package in the release pocket.
> the failing puma autopkg test in -proposed shouldn't be any concern.
> Filed LP: #1824049 for that.
> Now we could go on removing puma from -proposed, and then rails should
> migrate. How can we do that without removal?
That's not what this says. This says that rails can't migrate because it
depends on the version of puma to migrate first; and puma doesn't migrate
because the version of puma in proposed has failing autopkgtests; and the
old version of puma was removed during the bionic release cycle, by you,
because it failed to build.
Removing puma from -proposed would not make rails migratable. It would just
make rails uninstallable in -proposed.
And given that the puma package had autopkgtests that previously passed
during the bionic cycle, and which continue to pass in Debian, I'm not
willing to assume that this test failure is ignorable and doesn't constitute
a serious problem in the package. It's one thing to not block on test
failures that are also reproducible in the release pocket, because these are
not regressions and we can be confident that we are not making the quality
of the release worse by ignoring the test failure to let the newer version
into the release. It's another thing to not block on test failures for a
package whose autopkgtests succeeded before the package itself was removed.
I don't think there's a clear principle we can apply in the second case that
supports a policy of ignoring the test failure without examining the
specifics (and it's the examination of the specifics that takes time and
Here's another angle on why I don't think it's obviously correct to ignore
the test failures. The reason given for removing the previous version of
the package was that it FTBFS. FTBFS does not always lead to removal of
packages; except when this blocks transitions, it's usually better to fix
the build failure when we can, and leave the failing package in the release
in the meantime. Build failures matter, because they make it harder to do
security updates etc; but they generally have very little direct impact on
the end user. So if puma hadn't been removed due to the build failure, but
had instead been released in that state (FTBFS but autopkgtests succeed),
would we then consider this puma acceptable to migrate, *without* having to
dig in and understand the test failure? (Increasing buildability of the
release, but decreasing testability)
I don't think we do want to consider that acceptable.
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 https://www.debian.org/