F36 Change: Golang 1.18 (System-Wide Change proposal)

[Ben Cotton]

Note that this replaces the approved Golang 1.17 Change

https://fedoraproject.org/wiki/Changes/golang1.18

== Summary ==
Rebase of Golang package to upcoming version 1.18 in Fedora 36,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).

== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: [e-mail], [e-mail]

== Detailed Description ==

Rebase of Golang package to upcoming version 1.18 in Fedora 36. Golang
1.18 is scheduled to be released in February 2022.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.

== Benefit to Fedora ==
Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.18 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.

== Scope ==
* Proposal owners: Rebase Golang package in Fedora 36, help resolve
possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild.
* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
None

== How To Test ==
;0.
:a) Install golang 1.18 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.18 should work as expected.

== User Experience ==

None

== Dependencies ==
<pre>
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q  --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed ~1600.
</pre>

Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.

== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.16.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No

== Documentation ==
https://tip.golang.org/doc/go1.18

[Fabio Valentini]

On Fri, Dec 17, 2021 at 12:54 AM Ben Cotton  wrote:
> Note that this replaces the approved Golang 1.17 Change
>
> https://fedoraproject.org/wiki/Changes/golang1.18
>
> == Summary ==
> Rebase of Golang package to upcoming version 1.18 in Fedora 36,
> including the rebuild of all dependent packages(the pre-release
> version of Go will be used for the rebuild if released version will
> not be available at the time of the mass rebuild).

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?
> == Contingency Plan ==
> Contingency mechanism:Reverting to golang version 1.16.X if
>
> significant issues are discovered.
> Contingency deadline: Beta Freeze(?)
> Blocks release? No
> Blocks product? No

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.

Fabio

[Alejandro Saez Morollon]

On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini 
wrote:
> On Fri, Dec 17, 2021 at 12:54 AM Ben Cotton  wrote:
> > Note that this replaces the approved Golang 1.17 Change
> >
> > https://fedoraproject.org/wiki/Changes/golang1.18
> >
> > == Summary ==
> > Rebase of Golang package to upcoming version 1.18 in Fedora 36,
> > including the rebuild of all dependent packages(the pre-release
> > version of Go will be used for the rebuild if released version will
> > not be available at the time of the mass rebuild).
>
> 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.
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.
> > == Contingency Plan ==
> > Contingency mechanism:Reverting to golang version 1.16.X if
> >
> > significant issues are discovered.
> > Contingency deadline: Beta Freeze(?)
> > Blocks release? No
> > Blocks product? No
>
> 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 :)
> Fabio
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Fabio Valentini]

On Sat, Dec 18, 2021 at 9:35 AM Alejandro Saez Morollon  wrote:
> On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini  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?
> 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).

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 :)

Fabio

[Alejandro Saez Morollon]

On Sat, Dec 18, 2021 at 12:35 PM Fabio Valentini 
wrote:
> On Sat, Dec 18, 2021 at 9:35 AM Alejandro Saez Morollon 
> wrote:
> > On Fri, Dec 17, 2021 at 3:14 PM Fabio Valentini
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Fabio Valentini]

On Tue, Dec 21, 2021 at 10:18 AM Alejandro Saez Morollon  wrote:
> I was planning on doing the first, push go 1.18 beta/rc to rawhide (beta1 is already there in fact).

Great, that's good to know.
It broke my only Go package, but at least go 1.18 is already in rawhide :)
> 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?

Go 1.17 has probably been in rawhide long enough that any big problems
should have been noticed already, so I don't think falling back to Go
1.17 for F36 should be a problem, in case 1.18 is very disruptive.

Fabio