Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34,
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:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jcajka(a)redhat.com, alexsaezm(a)redhat.com


== Detailed Description ==

Rebase of Golang package to upcoming version 1.16 in Fedora 34. Golang
1.16 is scheduled to be released in February 2021.
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.16 . 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 34, help resolve
possible issues found
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking
issue.[https://pagure.io/releng/issue/9904]
* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
;0.
:a) Install golang 1.16 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.16 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.15.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No

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

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/golang1.16
>  
>  == Summary ==
>  Rebase of Golang package to upcoming version 1.16 in Fedora 34, 
No complaint about the Change, but...
can we please stop saying "rebase"?

That verb made sense when packaging was about a stack of patches and
hacks. Nowadays maybe 90% of packages are just the upstream version,
and another 9% have patches backported from git that will be dropped
on the update to the next upstream version. Talking about a "rebase"
is mostly confusing.

"Update" FTW!

Zbyszek

[Robbie Harwood]

Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:

>  On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/golang1.16
> > 
> > == Summary ==
> > Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>
>  No complaint about the Change, but...
>  can we please stop saying "rebase"?
>
>  That verb made sense when packaging was about a stack of patches and
>  hacks. Nowadays maybe 90% of packages are just the upstream version,
>  and another 9% have patches backported from git that will be dropped
>  on the update to the next upstream version. Talking about a "rebase"
>  is mostly confusing. 
Not really a defense, but this is what we call it internally for RHEL.
So even if we officially change the name, most of us are likely to keep
calling it rebase out of habit.

(And it does make sense for RHEL where backporting more patches is the
norm.  I'm uncomfortable with the assertion that ~99% of all packages
have no downstream-only packages, but that might just be my bias in the
opposite direction, since I maintain a couple that do.)

Thanks,
--Robbie

[Josh Boyer]

On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:
>
>  > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>  >> https://fedoraproject.org/wiki/Changes/golang1.16
>  >>
>  >> == Summary ==
>  >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>  >
>  > No complaint about the Change, but...
>  > can we please stop saying "rebase"?
>  >
>  > That verb made sense when packaging was about a stack of patches and
>  > hacks. Nowadays maybe 90% of packages are just the upstream version,
>  > and another 9% have patches backported from git that will be dropped
>  > on the update to the next upstream version. Talking about a "rebase"
>  > is mostly confusing.
>
>  Not really a defense, but this is what we call it internally for RHEL.
>  So even if we officially change the name, most of us are likely to keep
>  calling it rebase out of habit. 
I agree with you, Robbie.  It'll hang around and we'll have to deal
with it for a long time.

However, even internally in RHEL we're starting to see "rebase" be
really hard to understand.  One team will mean "grab a new tarball
that only contains a limited set of bug fixes" and another team will
mean "grab an entirely new major version release that breaks ABI and
on-disk format".  We should honestly look at how to articulate these
kinds of things better, both in Fedora and in RHEL.  "Rebase" is
quickly becoming meaningless.

josh

> (And it does make sense for RHEL where backporting more patches is the
> norm.  I'm uncomfortable with the assertion that ~99% of all packages
> have no downstream-only packages, but that might just be my bias in the
> opposite direction, since I maintain a couple that do.)
>
> Thanks,
> --Robbie
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-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/[e-mail]

[Jakub Cajka]

----- Original Message -----
>  From: "Josh Boyer" <jwboyer(a)fedoraproject.org&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl&gt;
>  Sent: Tuesday, January 5, 2021 9:45:28 PM
>  Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
>  
>  On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  >
>  > Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:
>  >
>  > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>  > >> https://fedoraproject.org/wiki/Changes/golang1.16
>  > >>
>  > >> == Summary ==
>  > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>  > >
>  > > No complaint about the Change, but...
>  > > can we please stop saying "rebase"?
>  > >
>  > > That verb made sense when packaging was about a stack of patches and
>  > > hacks. Nowadays maybe 90% of packages are just the upstream version,
>  > > and another 9% have patches backported from git that will be dropped
>  > > on the update to the next upstream version. Talking about a "rebase"
>  > > is mostly confusing.
>  >
>  > Not really a defense, but this is what we call it internally for RHEL.
>  > So even if we officially change the name, most of us are likely to keep
>  > calling it rebase out of habit.
>  
>  I agree with you, Robbie.  It'll hang around and we'll have to deal
>  with it for a long time.
>  
>  However, even internally in RHEL we're starting to see "rebase" be
>  really hard to understand.  One team will mean "grab a new tarball
>  that only contains a limited set of bug fixes" and another team will
>  mean "grab an entirely new major version release that breaks ABI and
>  on-disk format".  We should honestly look at how to articulate these
>  kinds of things better, both in Fedora and in RHEL.  "Rebase" is
>  quickly becoming meaningless.
>  
>  josh 
I kind of agree with all that have been said and will add my point of view. First I think
that any term the we will invent or choose will eventually drift in way that we might not
agree with or want with little that anyone can do about it.

I would argue that in this case it is the most that rebase can be, especially with the
need to actually rebuild "all" the Go packages to pick up the changes in the
compiler and standard Go library. Not much on the compiler side as all the Fedora patches
doesn't really need much re-basing(mostly just setting some more saner defaults), but
the other packages are rebased in a sense on top of the new version of compiler.

I'm open to any improvement in the wording of the change, feel free to propose
something here or just edit the proposal, but please let me know as the wiki AFAIK
doesn't allow continuous notification on changes(or I haven't been able to find it
and enable it for myself).

JC

>  
>  > (And it does make sense for RHEL where backporting more patches is the
>  > norm.  I'm uncomfortable with the assertion that ~99% of all packages
>  > have no downstream-only packages, but that might just be my bias in the
>  > opposite direction, since I maintain a couple that do.)
>  >
>  > Thanks,
>  > --Robbie
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-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/[e-mail]
>

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote:
>  
>  
>  
>  
>  ----- Original Message -----
>  > From: "Josh Boyer" <jwboyer(a)fedoraproject.org&gt;
>  > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl&gt;
>  > Sent: Tuesday, January 5, 2021 9:45:28 PM
>  > Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
>  > 
>  > On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  > >
>  > > Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:
>  > >
>  > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>  > > >> https://fedoraproject.org/wiki/Changes/golang1.16
>  > > >>
>  > > >> == Summary ==
>  > > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>  > > >
>  > > > No complaint about the Change, but...
>  > > > can we please stop saying "rebase"?
>  > > >
>  > > > That verb made sense when packaging was about a stack of patches and
>  > > > hacks. Nowadays maybe 90% of packages are just the upstream version,
>  > > > and another 9% have patches backported from git that will be dropped
>  > > > on the update to the next upstream version. Talking about a
> "rebase"
>  > > > is mostly confusing.
>  > >
>  > > Not really a defense, but this is what we call it internally for RHEL.
>  > > So even if we officially change the name, most of us are likely to keep
>  > > calling it rebase out of habit.
>  > 
>  > I agree with you, Robbie.  It'll hang around and we'll have to deal
>  > with it for a long time.
>  > 
>  > However, even internally in RHEL we're starting to see "rebase" be
>  > really hard to understand.  One team will mean "grab a new tarball
>  > that only contains a limited set of bug fixes" and another team will
>  > mean "grab an entirely new major version release that breaks ABI and
>  > on-disk format".  We should honestly look at how to articulate these
>  > kinds of things better, both in Fedora and in RHEL.  "Rebase" is
>  > quickly becoming meaningless.
>  > 
>  > josh
>  
>  I kind of agree with all that have been said and will add my point of view. First I think
> that any term the we will invent or choose will eventually drift in way that we might not
> agree with or want with little that anyone can do about it.
>  
>  I would argue that in this case it is the most that rebase can be, especially with the
> need to actually rebuild "all" the Go packages to pick up the changes in the
> compiler and standard Go library. Not much on the compiler side as all the Fedora patches
> doesn't really need much re-basing(mostly just setting some more saner defaults), but
> the other packages are rebased in a sense on top of the new version of compiler. 
So... the compiler is *updated** and the packages are **rebuilt**?
"""
 The Go compiler is updated to the upcoming version 1.16 in Fedora 34,
 and all golang packages are rebuilt. (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). 
"""
?

>  I'm open to any improvement in the wording of the change, feel
> free to propose something here or just edit the proposal, but please let me know as the
> wiki AFAIK doesn't allow continuous notification on changes(or I haven't been able
> to find it and enable it for myself). 
There's a "watch" button topright, and also when editing, you are asked
if you want to be notified about changes. I think I always get an email
when somebody changes a page I'm watching.

>  > > (And it does make sense for RHEL where backporting more
> patches is the
>  > > norm.  I'm uncomfortable with the assertion that ~99% of all packages
>  > > have no downstream-only packages, but that might just be my bias in the
>  > > opposite direction, since I maintain a couple that do.) 
Yeah, my numbers were cut from straight cloth ;) It'd be interesting to have
some real data. 

Zbyszek

[Elliott Sales de Andrade]

On Wed, 6 Jan 2021 at 05:12, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote:
>  >
>  > ----- Original Message -----
>  > > From: "Josh Boyer" <jwboyer(a)fedoraproject.org&gt;
>  > > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > > Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl&gt;
>  > > Sent: Tuesday, January 5, 2021 9:45:28 PM
>  > > Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
>  > >
>  > > On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood <rharwood(a)redhat.com&gt;
> wrote:
>  > > >
>  > > > Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:
>  > > >
>  > > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>  > > > >> https://fedoraproject.org/wiki/Changes/golang1.16
>  > > > >>
>  > > > >> == Summary ==
>  > > > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>  > > > >
>  > > > > No complaint about the Change, but...
>  > > > > can we please stop saying "rebase"?
>  > > > >
>  > > > > That verb made sense when packaging was about a stack of patches and
>  > > > > hacks. Nowadays maybe 90% of packages are just the upstream version,
>  > > > > and another 9% have patches backported from git that will be dropped
>  > > > > on the update to the next upstream version. Talking about a
> "rebase"
>  > > > > is mostly confusing.
>  > > >
>  > > > Not really a defense, but this is what we call it internally for RHEL.
>  > > > So even if we officially change the name, most of us are likely to keep
>  > > > calling it rebase out of habit.
>  > >
>  > > I agree with you, Robbie.  It'll hang around and we'll have to deal
>  > > with it for a long time.
>  > >
>  > > However, even internally in RHEL we're starting to see "rebase"
> be
>  > > really hard to understand.  One team will mean "grab a new tarball
>  > > that only contains a limited set of bug fixes" and another team will
>  > > mean "grab an entirely new major version release that breaks ABI and
>  > > on-disk format".  We should honestly look at how to articulate these
>  > > kinds of things better, both in Fedora and in RHEL.  "Rebase" is
>  > > quickly becoming meaningless.
>  > >
>  > > josh
>  >
>  > I kind of agree with all that have been said and will add my point of view. First I
> think that any term the we will invent or choose will eventually drift in way that we
> might not agree with or want with little that anyone can do about it.
>  >
>  > I would argue that in this case it is the most that rebase can be, especially with
> the need to actually rebuild "all" the Go packages to pick up the changes in the
> compiler and standard Go library. Not much on the compiler side as all the Fedora patches
> doesn't really need much re-basing(mostly just setting some more saner defaults), but
> the other packages are rebased in a sense on top of the new version of compiler.
>
>  So... the compiler is *updated** and the packages are **rebuilt**?
>  """
>   The Go compiler is updated to the upcoming version 1.16 in Fedora 34,
>   and all golang packages are rebuilt. (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).
>  """
>  ?
>
>  > I'm open to any improvement in the wording of the change, feel free to propose
> something here or just edit the proposal, but please let me know as the wiki AFAIK
> doesn't allow continuous notification on changes(or I haven't been able to find it
> and enable it for myself).
>
>  There's a "watch" button topright, and also when editing, you are asked
>  if you want to be notified about changes. I think I always get an email
>  when somebody changes a page I'm watching.
>
>  > > > (And it does make sense for RHEL where backporting more patches is the
>  > > > norm.  I'm uncomfortable with the assertion that ~99% of all packages
>  > > > have no downstream-only packages, but that might just be my bias in the
>  > > > opposite direction, since I maintain a couple that do.)
>
>  Yeah, my numbers were cut from straight cloth ;) It'd be interesting to have
>  some real data. 
As a first order estimate, it's rather straightforward to grab the
spec tarball and count the number of Patch lines in each one (which
ignores any fanciness with Lua or conditionals, and doesn't really say
if they are downstream-only, exactly).

The top ten count percentages are:
0      71.5054
1      14.7853
2      5.6351
3      2.7172
4      1.4361
5      0.9893
6      0.6611
7      0.4468
8      0.3419
9      0.2234
10     0.1824
> 10     1.0760 
So at minimum 71.5% have no downstream-only patches. I _think_
packages with fewer patches are ones that will likely go upstream (as
having more patches might indicate that upstream is dead/dying/slow to
release), so the remaining ones with less than 5 are _likely_ to go
upstream. Just guessing that's about half of those would be another
~12%, so around 84%.

For anyone interested in top-patchers:
                         patch_count
cc65                             170
gcl                              129
device-mapper-multipath           87
python3-rpm                       81
luajit                            79
ksh                               71
kdelibs3                          68
vsftpd                            68
acpica-tools                      62
ovn                               61

>  Zbyszek 
-- 
Elliott

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 06, 2021 at 06:07:40AM -0500, Elliott Sales de Andrade wrote:
>  As a first order estimate, it's rather straightforward to grab
> the
>  spec tarball and count the number of Patch lines in each one (which
>  ignores any fanciness with Lua or conditionals, and doesn't really say
>  if they are downstream-only, exactly).
>  
>  The top ten count percentages are:
>  0      71.5054
>  1      14.7853
>  2      5.6351
>  3      2.7172
>  4      1.4361
>  5      0.9893
>  6      0.6611
>  7      0.4468
>  8      0.3419
>  9      0.2234
>  10     0.1824
>  >10     1.0760
>  
>  So at minimum 71.5% have no downstream-only patches. I _think_
>  packages with fewer patches are ones that will likely go upstream 
Many thanks for calculating those statistics!

Even looking at the list below, not "go upstream", but "come from
upstream".
That is one of the changes from what was happening 10 years ago and now
that I was trying to highlight. We pull patches from upstream repos, and
more rarely then before generate them downstream. And even if we generate
them downstream, we're more likely to immediately submit them as pull requests
or such. (In particular, when trying to fix some build or failing test,
I find it less work to clone the upstream repo and work there and immediately
submit a pull request and use Patch0: https://github.com/.../something.patch
in the spec file, so that I can do 'spectool -g *spec', instead of generating
the patch file myself.)

I'm pretty sure that the 81 python3-rpm are backports from upstream. The 129
patches for gcl seems to be upstream prerelase patches. When upstream makes the
next release, no "rebase" is needed — those patches will be just dropped.

Zbyszek

> having more patches might indicate that upstream is dead/dying/slow to
> release), so the remaining ones with less than 5 are _likely_ to go
> upstream. Just guessing that's about half of those would be another
> ~12%, so around 84%.
> 
> For anyone interested in top-patchers:
>                          patch_count
> cc65                             170
> gcl                              129
> device-mapper-multipath           87
> python3-rpm                       81
> luajit                            79
> ksh                               71
> kdelibs3                          68
> vsftpd                            68
> acpica-tools                      62
> ovn                               61

[Jakub Cajka]

----- Original Message -----
>  From: "Zbigniew Jędrzejewski-Szmek"
> <zbyszek(a)in.waw.pl&gt;
>  To: "Jakub Cajka" <jcajka(a)redhat.com&gt;
>  Cc: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, January 6, 2021 11:10:58 AM
>  Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
>  
>  On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote:
>  > 
>  > 
>  > 
>  > 
>  > ----- Original Message -----
>  > > From: "Josh Boyer" <jwboyer(a)fedoraproject.org&gt;
>  > > To: "Development discussions related to Fedora"
>  > > <devel(a)lists.fedoraproject.org&gt;
>  > > Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl&gt;
>  > > Sent: Tuesday, January 5, 2021 9:45:28 PM
>  > > Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
>  > > 
>  > > On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood <rharwood(a)redhat.com&gt;
>  > > wrote:
>  > > >
>  > > > Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:
>  > > >
>  > > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>  > > > >> https://fedoraproject.org/wiki/Changes/golang1.16
>  > > > >>
>  > > > >> == Summary ==
>  > > > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>  > > > >
>  > > > > No complaint about the Change, but...
>  > > > > can we please stop saying "rebase"?
>  > > > >
>  > > > > That verb made sense when packaging was about a stack of patches and
>  > > > > hacks. Nowadays maybe 90% of packages are just the upstream version,
>  > > > > and another 9% have patches backported from git that will be dropped
>  > > > > on the update to the next upstream version. Talking about a
> "rebase"
>  > > > > is mostly confusing.
>  > > >
>  > > > Not really a defense, but this is what we call it internally for RHEL.
>  > > > So even if we officially change the name, most of us are likely to keep
>  > > > calling it rebase out of habit.
>  > > 
>  > > I agree with you, Robbie.  It'll hang around and we'll have to deal
>  > > with it for a long time.
>  > > 
>  > > However, even internally in RHEL we're starting to see "rebase"
> be
>  > > really hard to understand.  One team will mean "grab a new tarball
>  > > that only contains a limited set of bug fixes" and another team will
>  > > mean "grab an entirely new major version release that breaks ABI and
>  > > on-disk format".  We should honestly look at how to articulate these
>  > > kinds of things better, both in Fedora and in RHEL.  "Rebase" is
>  > > quickly becoming meaningless.
>  > > 
>  > > josh
>  > 
>  > I kind of agree with all that have been said and will add my point of view.
>  > First I think that any term the we will invent or choose will eventually
>  > drift in way that we might not agree with or want with little that anyone
>  > can do about it.
>  > 
>  > I would argue that in this case it is the most that rebase can be,
>  > especially with the need to actually rebuild "all" the Go packages to
> pick
>  > up the changes in the compiler and standard Go library. Not much on the
>  > compiler side as all the Fedora patches doesn't really need much
>  > re-basing(mostly just setting some more saner defaults), but the other
>  > packages are rebased in a sense on top of the new version of compiler.
>  
>  So... the compiler is *updated** and the packages are **rebuilt**?
>  """
>   The Go compiler is updated to the upcoming version 1.16 in Fedora 34,
>   and all golang packages are rebuilt. (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).
>  """
>  ? 
Yes, thank you. Applied in to the wiki.

>  
>  > I'm open to any improvement in the wording of the change, feel free to
>  > propose something here or just edit the proposal, but please let me know
>  > as the wiki AFAIK doesn't allow continuous notification on changes(or I
>  > haven't been able to find it and enable it for myself).
>  
>  There's a "watch" button topright, and also when editing, you are asked
>  if you want to be notified about changes. I think I always get an email
>  when somebody changes a page I'm watching. 
This is in my experience reset with first edit after mine(both the top watch button or via
the edit submit screen), as in watch is still on, but I don't get any further
notifications.

JC

>  
>  > > > (And it does make sense for RHEL where backporting more patches is the
>  > > > norm.  I'm uncomfortable with the assertion that ~99% of all packages
>  > > > have no downstream-only packages, but that might just be my bias in the
>  > > > opposite direction, since I maintain a couple that do.)
>  
>  Yeah, my numbers were cut from straight cloth ;) It'd be interesting to have
>  some real data.
>  
>  Zbyszek
>  
>

[Jerry James]

On Wed, Jan 6, 2021 at 4:27 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  I'm pretty sure that the 81 python3-rpm are backports from
> upstream. The 129
>  patches for gcl seems to be upstream prerelase patches. When upstream makes the
>  next release, no "rebase" is needed — those patches will be just dropped.
The gcl situation is interesting.  Upstream essentially uses Debian as
its development platform.  Patches are added to the Debian package
without spinning a new tarball.  Even though many of the patches have
names of the form Version_2_6_13preXX, upstream treats the Debian
packages as continuations of the 2.6.12 series.  I periodically sync
up with the Debian package state and build a new Fedora package.
(Thanks for the prod; I've now added 2 more upstream patches to gcl!)

There are currently 118 upstream patches, and 13 downstream patches in
the gcl package.  The 13 downstream patches have nearly all been
applied to upstream's 2.7.x branch.  If 2.7 is ever actually released
(I have some doubts about that), we can throw away almost every
patches.  I think upstream will get around to releasing 2.6.13 some
day, and then we can drop the 118 upstream patches.  Upstream doesn't
release very often, in the sense of making a new versioned tarball.
Upstream releases fairly often in the sense of building a new Debian
package; I track that.
-- 
Jerry James
http://www.jamezone.org/

[Miro Hrončok]

On 06. 01. 21 12:26, Zbigniew Jędrzejewski-Szmek wrote:
>  I'm pretty sure that the 81 python3-rpm are backports from
> upstream. 
The python3-rpm package is an EPEL7 only package and there will be no rebase.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok