On Wed, 6 Jan 2021 at 05:12, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote: > > > > ----- Original Message ----- > > > From: "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> > > > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > > > Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek@xxxxxxxxx> > > > 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@xxxxxxxxxx> wrote: > > > > > > > > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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 _______________________________________________ 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
