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?
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.
> 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.
> > Pointing to the upstream language-specific repositories is problematic. These
> > are usually only well maintained for x86_64, maybe some have support for ARM32,
> > but many don't have support for newer architectures like arm64, ppc64el and
> > s390x, or have dropped support (like for ix86). Didn't Ubuntu promise to
> > support new architectures the same way we support x86_64?
> >
> > Even x86_64 specific upstream repositories can be problematic. Some
> > architecture specific Python manylinux wheels have subtle issues because they
> > are built on an old CentOS release, and you see issues in the Launchpad tracker
> > which wrongly attribute issues in these third party wheels to packages found in
> > Ubuntu. Well, manylinux should have been called somelinux or even centos...
> >
> > > So I agree with the general principle that we should be willing to remove
> > > such language-specific stacks from the archive if they are not being
> > > maintained (which, with my AA hat on, means: remove from devel and
> > > devel-proposed and add to the sync blacklist).
> > >
> > > I also agree for the specific case of rails that it should be removed from
> > > Ubuntu releases going forward, unless something changes; and I believe that
> > > we should put this into effect immediately for the Ubuntu 19.04 release,
> > > despite the nearness of the release date.
> > >
> > > Provided that there are no objections here, I will plan to start removing
> > > this stack from disco and disco-proposed on Friday, April 5.
> >
> > I disagree with this approach. There are at least two packages with failing
> > autopkg tests which were removed in Debian. So why are those not removed in
> > Ubuntu as well? I think we should fix our ubuntu-archive tasks first, and see
> > what kind of actions we are missing, and only then decide if those packages
> > should be removed or not.
> >
> > With your AA hat on, why are those removals not handled before proposing the
> > removal of every dependency?
> >
> > > (These removals are reversible right up until the day before release, so I
> > > don't see much point in a long comment period. If objections are raised
> > > after Friday, we can still revisit.)
> > >
> > > Here's a list of rails packages that look like immediate candidates for
> > > removal based on this hackish script:
> > >
> > [...]
> > > debci
> >
> > Is this a commitment of the ubuntu-release team to maintain the stack needed for
> > the autopkg tests outside the archive?
> >
> > Please don't get me wrong, I'm not a user of the rails stack, however I think we
> > should get our internal processes fixed first.
> >
> > Matthias
--
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/
slangasek@ubuntu.com vorlon@debian.org
