Bug#922340: unblock: open-build-service/2.9.4-1
Hello, Missatge de Jonathan Wiltshire del dia dg., 17 de març 2019 a les 19:04: > > Control: tag -1 moreinfo > > Hi, > > On Wed, Mar 06, 2019 at 11:51:45PM +0100, Hector Oron wrote: > > OK, I tried, and to be honest, stable isn't perfect either, since > > distro lifecycle is longer than application support, so not allowing > > newer upstream versions in stable is problematic security wise in the > > long term. open-build-service is not the only one in this category, > > there are many packages in the same situation and it'd be nice to find > > a common solution for all those. > > What is upstream's approach to stable security updates like? How long is a > stable series maintained? Is it realistic to cherry-pick fixes from new > upstream releases for buster's lifetime? > > New upstreams in stable aren't a problem in themselves, but when not all > new upstream releases are suitable (e.g. mixing bug fixes and features) the > effect can be to block further releases, and make fixing high severity bugs > harder. I have been discussing with my colleagues about current state of the package and it needs a bit more polishing, hence we are fine with closing this unblock as Paul did. We'll look into alternative ways to distribute the package for the next stable distribution. Thanks, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#922340: unblock: open-build-service/2.9.4-1
Control: tag -1 moreinfo Hi, On Wed, Mar 06, 2019 at 11:51:45PM +0100, Hector Oron wrote: > OK, I tried, and to be honest, stable isn't perfect either, since > distro lifecycle is longer than application support, so not allowing > newer upstream versions in stable is problematic security wise in the > long term. open-build-service is not the only one in this category, > there are many packages in the same situation and it'd be nice to find > a common solution for all those. What is upstream's approach to stable security updates like? How long is a stable series maintained? Is it realistic to cherry-pick fixes from new upstream releases for buster's lifetime? New upstreams in stable aren't a problem in themselves, but when not all new upstream releases are suitable (e.g. mixing bug fixes and features) the effect can be to block further releases, and make fixing high severity bugs harder. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Bug#922340: unblock: open-build-service/2.9.4-1
Hello again, Besides what was mentioned in the previous email, I would like to clarify that we commit to open-build-service active maintenance since it is used in production by us. Regarding security we have already discussed with security team adding a note in the package clarifying security implications and doing recommendations to the potential users on whether running a public instance is discouraged. Regards
Bug#922340: unblock: open-build-service/2.9.4-1
Hello, Missatge de Jonathan Wiltshire del dia dc., 6 de març 2019 a les 22:59: > On Thu, Feb 14, 2019 at 08:19:10PM +0100, Héctor Orón Martínez wrote: > > A lot of effort has been put into `open-build-service`, since ruby rails > > 5 transition needed to happen and it did. Even uploading the package > > on-time it was delayed due to a couple dependencies: `ruby-clockwork` and > > `ruby-jquery-ui-rails`. > > I don't wish to detract from that effort, but it's not a valid reason on > its own for the unblock of a package not even in testing. > > With open-build-service being out of testing for nearly a year, Newer `open-build-service` had a dependency on ruby rails 5, which we have been coordinating with gitlab maintainers, because gitlab did not support rails 5 until very recently, so we started rails 5 transition in experimental, and barely made it to transition freeze. > dependencies also not in testing (and my feelings on them are similar), and While `open-build-service` was ready, some of the dependencies prevent it from migrating to testing, which was very unfortunated. > a popcon of just 10 or so, I think a better pathway would be via Right, not many popcon users, however it has it's users and ease the Debian derivative distro maintenance, for instance, it is used by Apertis, SteamOS, Endless Debian derivatives. Sylvestre has been using it for LLVM work as well. And it is being used by Linaro as well for distro work for the ARM architecture. > buster-backports when that is open. While we have thought about maintaining `open-build-service` newer versions in `stretch-backports`, it has not been possible due to webUI ruby dependencies and the way ruby is packaged in Debian, it makes it very hard to align all dependencies to have a working set. While buster-backports would be awesome to have, I do not think is going to work, since ruby versions do not remain compatible with older ones. We have also thought on changing the paradigm and package the backend services (perl) separated from webui (ruby) and provide webui in a container and install gems with ruby package manager instead as a work around, since doing the Debian way with rubygems is quite painful, but if you have any other good ideas we'd love to hear them. > I'm open to be pursuaded. OK, I tried, and to be honest, stable isn't perfect either, since distro lifecycle is longer than application support, so not allowing newer upstream versions in stable is problematic security wise in the long term. open-build-service is not the only one in this category, there are many packages in the same situation and it'd be nice to find a common solution for all those. Thanks for considering, I know it is not an easy call to do, so I'll understand either way you decide. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#922340: unblock: open-build-service/2.9.4-1
Control: tag -1 moreinfo On Thu, Feb 14, 2019 at 08:19:10PM +0100, Héctor Orón Martínez wrote: > A lot of effort has been put into `open-build-service`, since ruby rails > 5 transition needed to happen and it did. Even uploading the package > on-time it was delayed due to a couple dependencies: `ruby-clockwork` and > `ruby-jquery-ui-rails`. I don't wish to detract from that effort, but it's not a valid reason on its own for the unblock of a package not even in testing. With open-build-service being out of testing for nearly a year, dependencies also not in testing (and my feelings on them are similar), and a popcon of just 10 or so, I think a better pathway would be via buster-backports when that is open. I'm open to be pursuaded. > I am not attaching a debdiff since it is a major upstream version update. A debdiff something not in testing doesn't make sense anyway. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Bug#922340: unblock: open-build-service/2.9.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package open-build-service A lot of effort has been put into `open-build-service`, since ruby rails 5 transition needed to happen and it did. Even uploading the package on-time it was delayed due to a couple dependencies: `ruby-clockwork` and `ruby-jquery-ui-rails`. Please consider an exception and allow `open-build-service` into Buster release. I am not attaching a debdiff since it is a major upstream version update. You might check gitlab instead at: https://salsa.debian.org/ruby-team/open-build-service And its dependencies at: https://salsa.debian.org/ruby-team/ruby-clockwork https://salsa.debian.org/ruby-team/ruby-jquery-ui-rails unblock open-build-service/2.9.4-1 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8), LANGUAGE=ca_AD:ca (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
