On Sat, Dec 18, 2021 at 12:35 PM Fabio Valentini <decatho...@gmail.com> wrote:
> On Sat, Dec 18, 2021 at 9:35 AM Alejandro Saez Morollon <a...@redhat.com> > wrote: > > > > > > > > On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini <decatho...@gmail.com> > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
