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

Re: Backporting ruby 2.7 for gitlab
On Tue, Jun 30, 2020 at 09:26, Antonio Terceiro <terceiro@debian.org> wrote: 
On Tue, Jun 30, 2020 at 05:21:53PM +0530, Pirate Praveen wrote:

 Hi,
gitlab stopped working with ruby 2.5 (they officially dropped support long 
 ago, but it was working fine till now). See
https://gitlab.com/gitlab-org/gitlab/-/issues/225251 for details. In last stable release we were lucky things worked with ruby 2.3 even though it was 
 not officially supported.

 Option 1. Backport ruby 2.7
I could upload it to fasttrack as well, but I'd prefer more people benefit it by having it in backports since I'm doing the backport work anyway. 

 On a gitlab installation,
 $ ls /usr/share/rubygems-integration/2.5.0/specifications/ -1 |wc -l
 47

 So we will have to backport at least these many modules as well.

 Option 2. Patch gitlab to work with ruby 2.5
We can also try to fix issues with ruby 2.5 as and when we notice it as well, but if there not many takers for it, I don't think that can work well.
Option 1 requires only packaging knowledge but Option 2 requires ruby 
 knowledge.


For such a backport to work for gitlab, you would need to either a)
backport ruby-defaults as well to make /usr/bin/ruby by ruby2.7 or b)
change all binaries in gitlab to use /usr/bin/ruby2.7 explicitly.

a) is very risky as none of the other Ruby software in stable has been
tested with ruby2.7. This will cause random stuff to break and I don't
want to be involved in supporting that.
Thanks for your input. Though only someone explicitly installing ruby from backports will get ruby 2.7 so it is not correct to say it is going to regular stable. And all gitlab dependencies are already tested with ruby 2.7 in unstable.
b) requires changing gitlab somehow anyway, so you might as well fix the actual issues with ruby2.5 instead. FWIW I don't think it's realistic to 
maintain a fast-moving, enormous beast such as gitlab for stable and
expect to not need to get your hands dirty in its code.
Like I said, it is about what expertise you need. For backporting, I can use the expertise I already have in backporting and depend on upstream for ruby specific help if I stay close to what they officially support (if the issue is reproducible in their ci). I'd have to get into ruby code often, but if some of it can be avoided, by even having to do some extra work, I'd prefer to.
Anyway this specific issue is resolved and I will consider this again if/when we get such issues in future. Thanks for the patch.
I'd still like to know if anyone else in the team would be interested in maintaining such a backport. If no one volunteers, I can still have it in fasttrack, which will affect only gitlab users (for now, no other software in there yet).
Reply to: