Tuesday 9 April 2019

Re: Proposal: drop rails and its reverse-dependencies from Ubuntu 19.04 [Re: Maintaining language-specific module package stacks]

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAlytawcACgkQ4n8s+EWM
L6QBNA//UtEsSr0UdTpplghvVkVrQkUM/NdCh904nPRA+smHSBk8WvdphOd7GLo1
5SlA6lyLGNYn+vdRqH7NcRWeOyqRWxi74RRHK3kKCRfALAjTdQgjN6a4BhRayAqv
PJlVmWeBZ5Gp75oHN9AtgwLVgd8icWeykWECtyHYUNMBd+eC7pM3g1aWeoHAjtWf
scLjqWQ++tN4EObNTl/msJhW1KwMOpi1lGsGrp0mEtufvtVzZSv8SR5Gi1EZioen
+13HOA6ml/YBpFtAnzK18g0Z7AGc1k7DTzfQVXzcITjDxuTeLL+ALxP65cGc8WiL
J1U/fgZ5l9ZKItKhjjMR/Cg4d0xLJu1tIXgktiG2SOfHFlOz2+KjICo/8nTCsnsc
L66qZLnRV9B3uzSGCi8hgK6GFq6DAYjKCEJqAQTx7qMbw3lwoI7+Z55AH8DP2CDG
1cXrkJzAeUDrWcDjKX+KG0nhGlnp4dclKTfRDi26psHuGSxkO8cyrp7DguE7mh+h
5/Jm224JywYhSlt8vrmCtx/cCLliNtNf+1zguljIZ+uCdagZBbON6HzKhNg47eHb
ork1bPMlC1R8IRfsG14Lksko8cjRKS3PZfvCuaAsE7Gxy++WhpjTX/bkfXZueTfk
xpKk2jNU5dfsspXlGnoq0LR7Xe48ooBvK2XdwJbs/Crk7z/Z6tE=
=GthJ
-----END PGP SIGNATURE-----
On 4/9/19 10:53 PM, Matthias Klose wrote:
> On 10.04.19 05:48, Simon Quigley wrote:
>> On 4/9/19 10:15 PM, Matthias Klose wrote:
>>> On 10.04.19 04:37, Simon Quigley wrote:
>>>> On 4/9/19 9:27 PM, Matthias Klose wrote:
>>>>> 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?
>>>>
>>>> (disclaimer: not on the release team)
>>>>
>>>> This isn't a bug in Britney; Britney is designed to block on *any*
>>>> autopkgtest failures if there aren't any test hints (thus, a documented
>>>> reason for it failing). Passing autopkgtests for all packages is a
>>>> release goal, and unless the package has a hint (which is an exception
>>>> to the rule), any failing autopkgtests shouldn't let a package into the
>>>> release pocket. This autopkgtest should be evaluated to see if it's a
>>>> real regression in rails or if it's puma autopkgtests not working properly.
>>>
>>> Call it a britney bug or a proposed-migration bug. But to what extent should we
>>> care about a regression which doesn't show in the software that we ship? It's
>>> certainly not contradicting your statement "Passing autopkgtests for all
>>> packages is a release goal", because puma then wouldn't be part of the release.
>>> Now remove rails and dependencies and you might be able to update to a new ruby
>>> version much earlier, with even more regressions outside the archive.
>>
>> I think we should care about it to the extent that we can ensure that
>> puma's failure is not caused by ruby.
>
> s/ruby/rails/ ? ruby currently isn't part of any migration.

Sorry; we are discussing this on a higher level and I overlooked it.

>> If puma's autopkgtests are
>> flaky/unfixable without Very Horrible Hacks, they should be hinted. If
>> the failures are irrelevant to the ruby update, ruby should be hinted
>> when all other rdep pass their tests. If the puma test failure is easy
>> to fix, we should solve that, and then we're done here. All of these
>> actions can be completed without the Archive Admins.
>
> But in this case, puma would migrate with rails and you have the incompatible
> puma and rails versions in the release pocket.

Not necessarily. puma is considered a candidate if its autopkgtests pass
or are hinted. rails itself can be hinted without puma being hinted,
while puma still fails (thus staying in proposed). One question we
should seek to answer is if this is a rails regression; if it is, it
might be a wider problem that we should solve in rails itself prior to
letting it migrate.

--
Simon Quigley
tsimonq2@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4