----- Original Message ----- I thought that we have agreed on Go SIG meeting with eclipseo to do this in side tag along with golang rebase(to avoid 2 rebuilds), so there is no observable breakage(if any would occur) for package builds and all packages "just" pop in using new macros and following new guidelines. Currently following packages are FTBFS due to this change https://apps.fedoraproject.org/koschei/affected-by/go-srpm-macros?epoch1=... (thanks to qulogic for this query). And still we will have to do the side tag rebuild(for this change). We could have done that in one pass without causing any observable breakage for anyone. It seems that this change has been accepted as Self Contained Change but IMHO it is System Wide Change as it seems to affect (nearly) all Go based packages in distribution(and will require work/attention of people that are not change owners, actually not accounted for in change proposal). For past several releases I have been doing rebase of Go compiler change(yet to be filed for F31) that is IMHO comparable(maybe a bit smaller) in scope and they were always deemed by FESCO as System Wide Changes. This really leaves me confused. Could someone from FESCO clarify? When this has been discussed, new macros have been presented to me as backwards compatible(i.e. current packages will work and build as is, although requiring refresh to adopt new features), so it has not been concern for me. Other issue that I have is that you have not communicated this change(landing the new macro package) prior it happening here or elsewhere. I'm a Go SIG member(and maintainer of the previous macros packages, which by the way are still out there) and I have not been aware of this pending change landing now. I would much appreciate if you would communicate a bit more before landing such a big changes(go-rpm-package) in future, it would made possible to avoid some breakages, collect feedback and improve overall packagers experience. I think that communication is not easy, at least not for me, and I don't think that it is my strong skill, but we shouldn't resign on it as it is IMO crucial part of the Fedora community. Is there something that can I do to improve the information flow from my side? JC > > It opens the way to a mass cleanup and refresh of the Fedora Go stack. > https://pagure.io/packaging-committee/issue/901 > > A preview of this refresh is available here: > https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/ > > Enormous thanks to > – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing > updating and cleaning-up all those packages, and to > – Elliott Sales de Andrade (Qulogic), that picked up maintenance of > golist and fixed many of its long-standing bugs and limitations. > > Many thanks to the mock, rpm and redhat-rpm-config maintainers, > that integrated the changes, we built upon (Igor Gnatenko, Florian > Festi, Miroslav Suchý, Panu Matilainen) > > The macro set supports Go DynamicBuildRequires > https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > > They will be usable in mock as soon as rpm 4.15 lands > https://fedoraproject.org/wiki/Changes/RPM-4.15 > > Use in koji or copr will have to wait for the corresponding refresh > buldsystem-side. So this part of the change is a technology preview for > now. > > Best regards, > > -- > Nicolas Mailhot > _______________________________________________ > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >

On Wed, Jun 12, 2019 at 04:39:07AM -0400, Jakub Cajka wrote: https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes says So in this case, even though the change affects so many packages, it falls into the "self contained change" category. That said, the difference between "system-wide" and "self-contained" boils down to two things: some additional data required in the change page, and filing the change a bit earlier. In this case the additional data is mostly there in the change page, and the change was filed early, so even if we were to change the Change to "system-wide", the effect would be cosmetic. Zbyszek

----- Original Message ----- Thank you for clarification :). IMO it would be great if that has been recorded in https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes, this approach can't be really inferred from it(at least I don't see it there). With that popped on my mind that may be calling it "early/late window change" would fit better along with recording the complexity of the change, rather then system wide, contained change. But this is really just my brain storm. Unfortunately no early changes for me as Golang release are aligned late in to the Fedora devel cycle. JC > _______________________________________________ > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >

Hi, Yes, sure, if you can that would be appreciated. The vast majority of packages is easy to clean up (just adapt the templates in go-rpm- templates or use go2rpm), it's just there is an awful lot of them, so Robert-André Mauchin (eclipseo) can not do all of them in a single pass. If you hit one of the cases where a project needs weird stuff, or if you do not understand something, there is help available here and in the #fedora-golang channel. Please just state here (or tell eclispeo directly) what you will convert, so you do not end up doing the same work in parallel. Quite often, eclipseo will have prepared things in his copr, just not built them in koji yet. https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/ So taking up from where he prepared, and checking the result builds in koji and works for you, will accelerate things. @eclipseo: please correct if I wrote something that does not make things easier your side Regards, -- Nicolas Mailhot

On Saturday, 29 June 2019 09:26:20 CEST Nicolas Mailhot via devel wrote: DO NOT TOUCH ANY PACKAGES BEFORE I FINISH WITH F31-GO. Otherwise I'll need to rebase my git and it will be a PITA. All packages are being updated anyway. As for your Deepin packages, Robin, I have updated according to your work on COPR.