Vít Ondruch wrote on 2022/01/18 17:15:
Dne 18. 01. 22 v 8:44 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 2022/01/18 0:15:
Hi,
It is time of the year when new version of Ruby was released upstream and we should land it in Fedora. Unfortunately, the change proposal was approved just last Thursday and on top of that, rebase of libffi broke Ruby (I am going to disable the failing test cases for the moment and hope for the best). So this brings us into situation, where won't have enough time prior Fedora Mass rebuild. I have discussed this a bit with relengs and one of the options would be to build Ruby early during the mass rebuild and fix the outfall later. I shared the proposal in the Fedora Mass rebuild ticket [2]. One downside would be that in case of problems, we could not trigger our contingency plan, which is "drop our side tag". But I hope we won't need that.
Any thoughts?
My fist concern is that maybe we should build more then just Ruby. rubygem-json comes to my mind and possibly rubygem-nokogiri?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040380 [2] https://pagure.io/releng/issue/10538#comment-775197
My light idea is that as "Change Checkpoint" and "Branch Fedora Linux 36 from Rawhide" happends on 2022/Feb/08 (Tue),
Please note that this also marks end of mass rebuild phase.
I think we have enough time even if we start rebuilding with ruby31 beginning at, say, 2022/Jan/24 (Mon) or Jan/25
Right, I agree.
(if mass rebuild "really" begins tomorrow).
Yeah, this worries me, because I think that there used to be delays for past several occasions.
Or, once we can determine we wait rebuild until 2022/Jan/24 (Mon) or so on, and if mass rebuild doesn't go well by that day, we will force ruby rebuild anyway, for example.
One note: At least side-tag build can be done (queued) from the branch other than rawhide/main, (by specifying --release explicitly, like $ fedpkg --release f36 build --target f36-build-side-XXXXXX )
So you can - push ruby 3.1 change to ruby.git other than rawhide branch (say ruby31-temp branch) - create side-tag for ruby rebuild, build ruby3.1 on that side-tag from ruby.git ruby31-temp branch - At this time, mass rebuild can happen, but mass rebuild will happen using rawhide/main branch, so mass rebuild will be done using ruby3.0 - If that happen, merge rawhide and ruby31-temp (anyway), rebuild again on ruby31 side-tag - Then later, push bodhi to merge side-tag builds into rawhide
BTW Is your preference based on your availability or is that just considering the schedule and processes or what not?
Well, for my availability, although I cannot spare full time on ruby work (as I have my "daily" work), currently I have no worry for this and I can do rebuild of ruby related srpms at my own pace for the time being. So I am just considering the schedule for now.
Thx Vít
Regards, Mamoru