Hello all,
For the Fedorans among you (and Richard), you may be aware that a number of us met at Flock[0] and decided we wanted to do something about the poor state of affairs on supporting Go in Linux distributions. After the success we've had with Rust by collaborating with different distributions early on to have roughly unified packaging[1] (for the SUSE folks, yes, an OBS service for autogenerating crate packaging is in the works[2]), we want to try to replicate this success with Go.
This is a fairly opportune time to revisit how we approach Go in Linux distributions, as the Go ecosystem is finally starting to realize the folly of their approach to the ecosystem with the introduction of versioned modules as an eventual first class citizen[3].
In Fedora, we've been working on revisiting and improving our Go packaging, for both applications and modules. This has led to some interesting developments[4][5]. We've also built tools for supporting automating the management of Go packages (e.g. gofed). We're working on collecting all the various aspects of our Go tooling under our Pagure group[6].
I am aware that within the SUSE ecosystem, there's been some churn in how Go packaging works, and at this point, it's not really well-defined anymore (at least from my experience packaging Go stuff in openSUSE).
I would like to personally invite interested members of the (open)SUSE Go community to work with us in the Fedora Go SIG so that we can build better solutions for the Go ecosystem together. As I am both a member of Fedora and openSUSE, I am willing to assist with getting our solutions in place in both distributions.
Here are the major contact points for the Fedora Go SIG: * Mailing list: golang@lists.fedoraproject.org * IRC channel: #fedora-golang on Freenode * Forum section in Fedora Discourse: https://discussion.fedoraproject.org/c/go
Our current work is currently spread across Pagure, Dist-Git[7], and GitHub[8], and we're actively working on collecting everything in one place in our Pagure group so that it's easier to look over and contribute to.
Please let me know what you guys think, and I hope that we can work together to make a better future for Go in our Linux distributions!
[0]: https://flocktofedora.org/ [1]: https://fedoramagazine.org/oxidizing-fedora-try-rust-applications-today/ [2]: https://pagure.io/fedora-rust/obs-service-rust2rpm [3]: https://golang.org/doc/go1.11#modules [4]: https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation [5]: https://fedoraproject.org/wiki/More_Go_packaging [6]: https://pagure.io/group/GoSIG/ [7]: https://src.fedoraproject.org/ [8]: https://github.com/gofed
-- 真実はいつも一つ!/ Always, there's only one truth!
Adding Jeff, too
On 09/18/2018 01:35 PM, Neal Gompa wrote:
Hello all,
For the Fedorans among you (and Richard), you may be aware that a number of us met at Flock[0] and decided we wanted to do something about the poor state of affairs on supporting Go in Linux distributions. After the success we've had with Rust by collaborating with different distributions early on to have roughly unified packaging[1] (for the SUSE folks, yes, an OBS service for autogenerating crate packaging is in the works[2]), we want to try to replicate this success with Go.
This is a fairly opportune time to revisit how we approach Go in Linux distributions, as the Go ecosystem is finally starting to realize the folly of their approach to the ecosystem with the introduction of versioned modules as an eventual first class citizen[3].
In Fedora, we've been working on revisiting and improving our Go packaging, for both applications and modules. This has led to some interesting developments[4][5]. We've also built tools for supporting automating the management of Go packages (e.g. gofed). We're working on collecting all the various aspects of our Go tooling under our Pagure group[6].
I am aware that within the SUSE ecosystem, there's been some churn in how Go packaging works, and at this point, it's not really well-defined anymore (at least from my experience packaging Go stuff in openSUSE).
I would like to personally invite interested members of the (open)SUSE Go community to work with us in the Fedora Go SIG so that we can build better solutions for the Go ecosystem together. As I am both a member of Fedora and openSUSE, I am willing to assist with getting our solutions in place in both distributions.
Here are the major contact points for the Fedora Go SIG:
- Mailing list: golang@lists.fedoraproject.org
- IRC channel: #fedora-golang on Freenode
- Forum section in Fedora Discourse: https://discussion.fedoraproject.org/c/go
Our current work is currently spread across Pagure, Dist-Git[7], and GitHub[8], and we're actively working on collecting everything in one place in our Pagure group so that it's easier to look over and contribute to.
Please let me know what you guys think, and I hope that we can work together to make a better future for Go in our Linux distributions!
-- 真実はいつも一つ!/ Always, there's only one truth!
----- Original Message -----
From: "Neal Gompa" ngompa13@gmail.com To: golang@lists.fedoraproject.org, opensuse-go@opensuse.org Cc: "Aleksa Sarai" asarai@suse.de, "Richard Brown" RBrownCCB@opensuse.org, vrothberg@suse.com, jcajka@redhat.com Sent: Tuesday, September 18, 2018 1:35:36 PM Subject: Introducing the Fedora Go SIG and a proposal to build better Go packaging
Hello all,
For the Fedorans among you (and Richard), you may be aware that a number of us met at Flock[0] and decided we wanted to do something about the poor state of affairs on supporting Go in Linux distributions. After the success we've had with Rust by collaborating with different distributions early on to have roughly unified packaging[1] (for the SUSE folks, yes, an OBS service for autogenerating crate packaging is in the works[2]), we want to try to replicate this success with Go.
This is a fairly opportune time to revisit how we approach Go in Linux distributions, as the Go ecosystem is finally starting to realize the folly of their approach to the ecosystem with the introduction of versioned modules as an eventual first class citizen[3].
In Fedora, we've been working on revisiting and improving our Go packaging, for both applications and modules. This has led to some interesting developments[4][5]. We've also built tools for supporting
I would add here. Along with the forge macros and "More Go packaging" there needs to be mentioned the guidelines draft that is actually the base building block of Fedora's Go packaging(https://fedoraproject.org/wiki/PackagingDrafts/Go), that the [5] ignores and over simplifies in some areas(creating possible conflicts or ambiguities), but on the positive side adds some very good and useful ideas. Those two needs to be merged and all conflicts resolved. Hopefully we will achieve that soon along with approval of the draft(I'm trying to free up some time to do it.), as it got delayed due nim loosing interest in finishing the work(all the technical stuff should be already done, thanks to nim and jchaloup, just docs, guidelines are missing) that he started with the [5].
JC
automating the management of Go packages (e.g. gofed). We're working on collecting all the various aspects of our Go tooling under our Pagure group[6].
I am aware that within the SUSE ecosystem, there's been some churn in how Go packaging works, and at this point, it's not really well-defined anymore (at least from my experience packaging Go stuff in openSUSE).
I would like to personally invite interested members of the (open)SUSE Go community to work with us in the Fedora Go SIG so that we can build better solutions for the Go ecosystem together. As I am both a member of Fedora and openSUSE, I am willing to assist with getting our solutions in place in both distributions.
Here are the major contact points for the Fedora Go SIG:
- Mailing list: golang@lists.fedoraproject.org
- IRC channel: #fedora-golang on Freenode
- Forum section in Fedora Discourse:
https://discussion.fedoraproject.org/c/go
Our current work is currently spread across Pagure, Dist-Git[7], and GitHub[8], and we're actively working on collecting everything in one place in our Pagure group so that it's easier to look over and contribute to.
Please let me know what you guys think, and I hope that we can work together to make a better future for Go in our Linux distributions!
-- 真実はいつも一つ!/ Always, there's only one truth!
CCing Jeff :)
On 09/18/2018 02:45 PM, Jakub Cajka wrote:
----- Original Message -----
From: "Neal Gompa" ngompa13@gmail.com To: golang@lists.fedoraproject.org, opensuse-go@opensuse.org Cc: "Aleksa Sarai" asarai@suse.de, "Richard Brown" RBrownCCB@opensuse.org, vrothberg@suse.com, jcajka@redhat.com Sent: Tuesday, September 18, 2018 1:35:36 PM Subject: Introducing the Fedora Go SIG and a proposal to build better Go packaging
Hello all,
For the Fedorans among you (and Richard), you may be aware that a number of us met at Flock[0] and decided we wanted to do something about the poor state of affairs on supporting Go in Linux distributions. After the success we've had with Rust by collaborating with different distributions early on to have roughly unified packaging[1] (for the SUSE folks, yes, an OBS service for autogenerating crate packaging is in the works[2]), we want to try to replicate this success with Go.
This is a fairly opportune time to revisit how we approach Go in Linux distributions, as the Go ecosystem is finally starting to realize the folly of their approach to the ecosystem with the introduction of versioned modules as an eventual first class citizen[3].
In Fedora, we've been working on revisiting and improving our Go packaging, for both applications and modules. This has led to some interesting developments[4][5]. We've also built tools for supporting
I would add here. Along with the forge macros and "More Go packaging" there needs to be mentioned the guidelines draft that is actually the base building block of Fedora's Go packaging(https://fedoraproject.org/wiki/PackagingDrafts/Go), that the [5] ignores and over simplifies in some areas(creating possible conflicts or ambiguities), but on the positive side adds some very good and useful ideas. Those two needs to be merged and all conflicts resolved. Hopefully we will achieve that soon along with approval of the draft(I'm trying to free up some time to do it.), as it got delayed due nim loosing interest in finishing the work(all the technical stuff should be already done, thanks to nim and jchaloup, just docs, guidelines are missing) that he started with the [5].
JC
automating the management of Go packages (e.g. gofed). We're working on collecting all the various aspects of our Go tooling under our Pagure group[6].
I am aware that within the SUSE ecosystem, there's been some churn in how Go packaging works, and at this point, it's not really well-defined anymore (at least from my experience packaging Go stuff in openSUSE).
I would like to personally invite interested members of the (open)SUSE Go community to work with us in the Fedora Go SIG so that we can build better solutions for the Go ecosystem together. As I am both a member of Fedora and openSUSE, I am willing to assist with getting our solutions in place in both distributions.
Here are the major contact points for the Fedora Go SIG:
- Mailing list: golang@lists.fedoraproject.org
- IRC channel: #fedora-golang on Freenode
- Forum section in Fedora Discourse:
https://discussion.fedoraproject.org/c/go
Our current work is currently spread across Pagure, Dist-Git[7], and GitHub[8], and we're actively working on collecting everything in one place in our Pagure group so that it's easier to look over and contribute to.
Please let me know what you guys think, and I hope that we can work together to make a better future for Go in our Linux distributions!
-- 真実はいつも一つ!/ Always, there's only one truth!
Le mardi 18 septembre 2018 à 07:35 -0400, Neal Gompa a écrit : Hi,
In Fedora, we've been working on revisiting and improving our Go packaging, for both applications and modules. This has led to some interesting developments[4][5].
[4]:
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
Thanks
I'll just add that I'm currently finishing wrapping up the next generation of those, that will mainly change:
— for 4: ability to use several forge-hosted sources in one srpm (I don't like it, it reeks of bad packaging, but some people needed it) — for 5: same thing for Go packages + automation of Go buildrequires
It's an evolution, so usage will be quasi identical to what's on the wiki, with slight changes where it makes sense (for example, the macros will grow flags to select the archive to work on, when packaging several of those).
I hope that from now on we can continue to evolve the macro capabilities, to take into account changes in the Go language, while keeping the way they are used in spec files stable.
Regards,
golang@lists.fedoraproject.org