[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#922340: unblock: open-build-service/2.9.4-1



Hello,

Missatge de Jonathan Wiltshire <jmw@debian.org> 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  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


Reply to: