On 04.04.19 01:52, Steve Langasek wrote: > Thanks, Robie, for kicking off this discussion. > > In regards to rails in particular, I would like to note that the same > version of the rails package is present in the bionic, cosmic, and disco > releases. Despite several uploads and syncs/merges from Debian, no new > version of the rails package that has landed in devel-proposed has been > releasable to devel since 7 April 2018 > (https://launchpad.net/ubuntu/+source/rails/2%3A4.2.10-1/+publishinghistory). > > Autopkgtest results show that we do not have a coherent set of rails-related > packages in devel-proposed that are releasable. And despite the best > efforts of Ubuntu developers working on proposed-migration over the past > year, we have not succeeded in untangling this, in part because there is a > lack of expertise in this stack among those working on it. > > I think it's clear that this is a case where Ubuntu is not providing value > to our users by syncing the subset of modules that Debian have packaged, > particularly since - as you point out - we know that upstream is going to > recommend installing from the upstream language-specific repository (gems). > There's also no correlation between what version of these components was > current at the time of an Ubuntu release and what version is interesting for > deployment of real services over time.
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. 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
