On Sat, Dec 18, 2021 at 12:35 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
On Sat, Dec 18, 2021 at 9:35 AM Alejandro Saez Morollon <asm@xxxxxxxxxx> wrote:
>
>
>
> On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>>
>> Will there be a separate go 1.18 mass rebuild in rawhide?
>> Or will the f36 mass rebuild just happen with go 1.18 (beta/rc) present?
>>
>
> Given the release schedule, I highly doubt that a non beta/rc will be available at the time of the mass rebuild.
> It's not the first time this has happened as far as I'm aware. That's the problem with the Go schedule and why I sent an email couple days ago
> asking for input about it.
That's good and well, but doesn't answer my question. Do you plan to
- push go 1.18 (beta/rc, whatever is available at the time) to rawhide
in time for the normal f36 mass rebuild, or
- push go 1.18 *after* the f36 mass rebuild and do a separate mass
rebuild of Go packages?
I was planning on doing the first, push go 1.18 beta/rc to rawhide (beta1 is already there in fact).
> A solution to this situation will be to use modules and keep Fedora N in a previous release. But this does only solves
> the demands of the users, packages cannot use module streams, right?. Correct me if I'm wrong, please.
That is true. It would solve the problem for end users who install a
go compiler, but any Go packages in Fedora would still be stuck with
an EOL toolchain, and I don't think that would be acceptable.
>> If there's a separate mass rebuild (or any test builds with go 1.18)
>> planned prior to the mass rebuild, that's a bit of a tight timeline,
>> with the winter holidays coming up and the F36 mass rebuild planned to
>> start on Jan. 19, 2021.
>
> My biggest concern is that currently, we have 1.16 in Fedora 34 and Fedora 35.
> So if we can't update Fedora 36 to Go 1.18, by the EOL we will
> have a non upstream supported Go version with ~1900 packages depending on it.
> In that scenario, I would personally like to do a mass rebuild to make 1.17 available on Fedora 35 and 36.
> But I'm not sure about how possible this is.
>
> Any suggestion is highly welcome :)
Go 1.17 is already available for rawhide / f36, unless I am reading
the state of the package wrong. So even if you do *nothing*, the f36
mass rebuild will use Go 1.17. However, for f35 / f35, updating Golang
to 1.17 and rebuild almost ~2000 dependent packages in stable releases
won't be feasible, I think. Stable release workflow is just not
tailored towards supporting such big disruptive updates after release;
I think bodhi would just explode if you even tried to create an update
with that many packages in it (the problem of actually needing to
build all those packages without conflicts in a side tag, which is
even a problem if you only have a dozen packages).
Understood. That is a really important point :)
I also don't understand how the state of fedora 34 and 35 is impacting
the decisions around rawhide / f36. I just want to know whether you
think a golang 1.18 package will be ready in time for the f36 mass
rebuild, or if it will take longer, and require a second f36-golang
mass rebuild :)
Go 1.18 beta 1 is already in the rawhide branch, so I guess we won't need a second mass rebuild for golang.
Regarding the Fedora 34 /35 impacting the decision. What happens if, for whatever reason, 1.18 breaks a lot of builds and we decide to push back the update.
As 1.17 was never used in a mass rebuild, aren't the stable versions of Go more suitable for the fall-back mass rebuild?
Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
