> Hi Balint,
>
> On Thu, Apr 04, 2019 at 02:45:23PM +0200, Balint Reczey wrote:
>>> This is short-sighted, and greatly influenced by the voices of language-specific
>>> upstream communities. As seen at several occasions at PyCon: Ask an upstream
>>> community, which Linux distribution they use (majority of hands go up for
>>> Ubuntu), and then how many of those use the system Python (majority of hands go
>>> down). Please ask this Python question to an upstream Java, upstream Ruby
>>> community, and I assume that nobody cares and uses the Python as distributed by
>>> Ubuntu. Ask the Java and Python communities the same question about Ruby, and
>>> these are probably happy with the Ruby found on Ubuntu. Now remove the Ruby,
>>> Python and Java stacks, and probably nobody will be happy anymore.
>
>> This is very true and this is the raison d'être for distributions.
>
>> There is also a benefit of having the long tail packages in each
>> language stack that was not mentioned.
>
>> How would you test the ruby interpreter without the wast amount of
>> gems in the archive? With build-time or hand-made tests?
>
>> No. The autopkgtest infrastructure that continuously sweeps through
>> the packages in the archive catches the regressions that could have
>> been easily introduced to the archive, but without reverse
>> dependencies of the ruby interpreter no tests would be triggered and
>> we would ship an interpreter that would break our users' systems in
>> million ways.
>
> The critical limitation here is that an autopkgtest failure by itself only
> tells you "these two package versions when used together cause the test to
> fail". It takes effort to answer the subsequent questions:
>
> - Is this a valid test, or is it based on wrong assumptions?
> - Is this a regression in the interpreter, or a deliberate change in the
> language?
> - Is the package whose test is failing something that we should fix, or is
> it dead upstream and we should remove it?
you are missing here:
- is our test infrastructure reliable?
- are we running the test with the right assumptions?
- does our test infrastructure allow to pass autopkg tests in all
conditions?
But this probably is another thread ...
> These questions take even more effort to answer for ruby than for other
> languages, because the Ubuntu developers doing this investigation don't
> actually speak ruby.
>
> So no, I don't think the long tail of autopkgtests on ruby modules improves
> the quality of the intepreter, in proportion to the effort spent on
> analyzing the autopkgtest failures.
>
>> Even if big parts of the language stack's are somewhat outdated they
>> were tested together and provide a stable base for building systems on
>> and we should not just slash those big parts as a policy, only drop
>> the pieces which somehow got into the release pocket, but don't let
>> more important packages in due to failing autopkgtests or broken
>> builds.
>
> We don't really have a lightweight way of deciding that one package is "more
> important" than another, either.
we have that. It's called the main/universe split. This isn't reflected in
autopkg tests at all.
>> 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 escalations.
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?
So these removal requests come down to archive-removals not being processed on a
regular basis, and an additional removal or britney fix. Again, please lets fix
these issues first before relying on removals on a large style.
Matthias
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
