Dne 18. 01. 22 v 9:57 Mamoru TASAKA napsal(a):
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.
The agreement with relengs is that we will follow the Fedora mass rebuild:
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
_______________________________________________
ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraprojec...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure