Hey guys and gals,
Can we start to discuss this SIG goals? What each of you are expecting? A few ideas:
- Making https://fedoraproject.org/wiki/More_Go_packaging official and working on bringing them to EPEL7
- Assigning current Go packages to the SIG so each member of the SIG can work on them, similar to https://src.fedoraproject.org/group/rust-sig Many Google packages are inter-dependent, this would ease synchronising them.
- Working toward packaging more: I'm thinking about unbundling kubernetes and docker.
- Developing tools to maintain up-to-date our current set of Go packages, some of which are left outdated since their creation.
Any other ideas? I'd like to move forward as soon as possible.
Best regards,
Robert-André
----- Original Message -----
From: "Robert-André Mauchin" zebob.m@gmail.com To: golang@lists.fedoraproject.org, devel@lists.fedoraproject.org Sent: Friday, August 24, 2018 4:42:03 PM Subject: Golang SIG primary goals?
Hey guys and gals,
Can we start to discuss this SIG goals? What each of you are expecting
IMO meeting would be best so we can introduce ourselves. See my other email :)
I have taken liberty and have created pagure group https://pagure.io/group/GoSIG for the SIG and tracking project https://pagure.io/GoSIG/go-sig for all the ideas and work. I have added all folks listed in the wiki page to the group. Also there is issue for adding new members(or those that I have forgotten to add) https://pagure.io/GoSIG/go-sig/issue/1.
A few ideas:
- Making https://fedoraproject.org/wiki/More_Go_packaging official and
working on bringing them to EPEL7
Don't forget about EPEL6, too. ;)
I have created issue for the guidelines at the tracker. Along with some other that popped on my mind.
- Assigning current Go packages to the SIG so each member of the SIG can
work on them, similar to https://src.fedoraproject.org/group/rust-sig Many Google packages are inter-dependent, this would ease synchronising them.
- Working toward packaging more: I'm thinking about unbundling kubernetes
and docker.
- Developing tools to maintain up-to-date our current set of Go packages,
some of which are left outdated since their creation.
Any other ideas? I'd like to move forward as soon as possible.
Would you please create tracking issues(https://pagure.io/GoSIG/go-sig/new_issue) for the above ideas(or any other you might have) in the pagure project so we can discuss it there with better tracking/threading?
JC
Best regards,
Robert-André
golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-leave@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/golang@lists.fedoraproject.org...
Hi,
Just to get people thinking before the meet…
IMHO, the core objective of the SIG should be to maintain a consistent self-hosting up-to-date baseline of Go software in rpm form, that can then be used to build other forms of Fedora deliverables (flatpacks, coreos images, etc)
That implies: — continuing to improve the go/rpm plumbing (packager time should be spent on fixing project-specific problems, not writing lots of generic automatable declarations) – getting one form of Go packaging guidelines approved by FPC – producing a package set that conforms to the above – refreshing periodically the set (at least one mass rebuild/version refresh per Fedora release). – reporting upstream everything that fails in the set to raise the bar on the bits we package, gain legitimacy and provide value to upstream – ideally also work on fixes but just identifying and reporting problems regularly would be a huge first step – scrapping all the Fedora Go packages that do not comply. Not a fan of zero defect approaches but there is a point where keeping lots of obsolete/non conformant packages discourages old and new packagers alike
I don't really see the point of producing another set of bundled/containerized/imaged Go software, there are lots of them on the market, the drawbacks are increasingly well known (lots of rotting insecure third party code squirreled away inside the bundled sets), I'd rather have a smaller breadth of software that can demonstrate a software engineering approach than lots of half-assed packages that muddle waters and satisfy no one. Though given how Go software in massively reusing other code even focusing on a small set of apps will require a huge number of packages.
The areas that need work short term are:
A packaging
B cleaning up and consolidating guidelines (need to spread the load as it is quite soul crushing work).
C defining an org to import sets of Go packages within the SIG. Get approval to whatever changes in the Fedora process necessary to review and import easily apps spread over hundreds of packages (the Fedora process is really not geared towards apps that reuse hundreds of other projects and require hundreds of packages imported as a set)
D investigate vgo: 1. get POC support in go-macros (go-compiler & go-srpm-macros) 2. test if the result can be used : — are the module definitions written upstream forward-facing or locking specific version we can not use – Go devs could not write a dep engine that worked like the rest of the software world, rpm included, does it matter in practice if dependency declarations written for the Go dep engine are dumped in the rpm dep engine, that follows differing resolution rules 3. decide if we adopt vgo or not. If yes, probably easier to define how to write Fedora-friendly module definitions for projects that lack them than try to support an hybrid set of packages (with and without module defs). Module defs can be upstreamed as part of the packaging
E investigate automation of build requires (other SIGs did it but there's no support in rpm syntax for it, you need to talk to mock over a socket ie code a specific utility)
D. finishing a working baseline for Fedora Next, then rebase EPEL on it and forget about the past (the Go non compiler parts in EPEL have rotten to much for anyone to use, and I don't see anyone willing to invest the effort that would be required to salvage them in an evolutionary way, just accept it, get an exemption, and reboot from working Fedora state)
I could spend some time on most of those (though I'd rather pass on B, already done my part, and D/E would be the most fun and probably the most useful for the rest of the SIG).
However, my initial objectives were to produce clean prometheus and grafana Fedora packages, I finished the Go part a few months ago, but they both include a javascript layer, so I'll probably have to spend part of my packaging time on the js front. I'd really prefer if someone started a javascript SIG I could offload those to, I really don't have the cycles to progress quickly on packaging rules and tooling for two separate programming languages.
Regards,
On Tue, Aug 28, 2018 at 7:06 AM Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
However, my initial objectives were to produce clean prometheus and grafana Fedora packages, I finished the Go part a few months ago, but they both include a javascript layer, so I'll probably have to spend part of my packaging time on the js front. I'd really prefer if someone started a javascript SIG I could offload those to, I really don't have the cycles to progress quickly on packaging rules and tooling for two separate programming languages.
The NodeJS SIG absorbed the JavaScript SIG, so those are the folks to talk to.
Le 2018-08-28 13:27, Neal Gompa a écrit :
On Tue, Aug 28, 2018 at 7:06 AM Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
However, my initial objectives were to produce clean prometheus and grafana Fedora packages, I finished the Go part a few months ago, but they both include a javascript layer, so I'll probably have to spend part of my packaging time on the js front. I'd really prefer if someone started a javascript SIG I could offload those to, I really don't have the cycles to progress quickly on packaging rules and tooling for two separate programming languages.
The NodeJS SIG absorbed the JavaScript SIG, so those are the folks to talk to.
Thanks for the pointer, I'll contact them !
----- Original Message -----
From: "Nicolas Mailhot" nicolas.mailhot@laposte.net To: golang@lists.fedoraproject.org Cc: devel@lists.fedoraproject.org Sent: Tuesday, August 28, 2018 10:37:06 AM Subject: Re: Golang SIG primary goals?
Hi,
Just to get people thinking before the meet…
IMHO, the core objective of the SIG should be to maintain a consistent self-hosting up-to-date baseline of Go software in rpm form, that can then be used to build other forms of Fedora deliverables (flatpacks, coreos images, etc)
That implies: — continuing to improve the go/rpm plumbing (packager time should be spent on fixing project-specific problems, not writing lots of generic automatable declarations) – getting one form of Go packaging guidelines approved by FPC – producing a package set that conforms to the above – refreshing periodically the set (at least one mass rebuild/version refresh per Fedora release). – reporting upstream everything that fails in the set to raise the bar on the bits we package, gain legitimacy and provide value to upstream – ideally also work on fixes but just identifying and reporting problems regularly would be a huge first step – scrapping all the Fedora Go packages that do not comply. Not a fan of zero defect approaches but there is a point where keeping lots of obsolete/non conformant packages discourages old and new packagers alike
I don't really see the point of producing another set of bundled/containerized/imaged Go software, there are lots of them on the market, the drawbacks are increasingly well known (lots of rotting insecure third party code squirreled away inside the bundled sets), I'd rather have a smaller breadth of software that can demonstrate a software engineering approach than lots of half-assed packages that muddle waters and satisfy no one. Though given how Go software in massively reusing other code even focusing on a small set of apps will require a huge number of packages.
The areas that need work short term are:
A packaging
B cleaning up and consolidating guidelines (need to spread the load as it is quite soul crushing work).
C defining an org to import sets of Go packages within the SIG. Get approval to whatever changes in the Fedora process necessary to review and import easily apps spread over hundreds of packages (the Fedora process is really not geared towards apps that reuse hundreds of other projects and require hundreds of packages imported as a set)
D investigate vgo:
- get POC support in go-macros (go-compiler & go-srpm-macros)
- test if the result can be used : — are the module definitions written upstream forward-facing or
locking specific version we can not use – Go devs could not write a dep engine that worked like the rest of the software world, rpm included, does it matter in practice if dependency declarations written for the Go dep engine are dumped in the rpm dep engine, that follows differing resolution rules 3. decide if we adopt vgo or not. If yes, probably easier to define how to write Fedora-friendly module definitions for projects that lack them than try to support an hybrid set of packages (with and without module defs). Module defs can be upstreamed as part of the packaging
E investigate automation of build requires (other SIGs did it but there's no support in rpm syntax for it, you need to talk to mock over a socket ie code a specific utility)
D. finishing a working baseline for Fedora Next, then rebase EPEL on it and forget about the past (the Go non compiler parts in EPEL have rotten to much for anyone to use, and I don't see anyone willing to invest the effort that would be required to salvage them in an evolutionary way, just accept it, get an exemption, and reboot from working Fedora state)
Could you please turn those in to issue in pagure(https://pagure.io/GoSIG/go-sig/issues)? I don't believe that these ML will be best for keeping track of those and I'm afraid that they might stay rotting here.
I could spend some time on most of those (though I'd rather pass on B, already done my part, and D/E would be the most fun and probably the most useful for the rest of the SIG).
For B I would much appreciate if you would mark which parts of your proposals got implemented and in which way. It would greatly help anyone picking this topic after you. If you really do not plan to finish all the work that you have started.
Thanks,
JC
However, my initial objectives were to produce clean prometheus and grafana Fedora packages, I finished the Go part a few months ago, but they both include a javascript layer, so I'll probably have to spend part of my packaging time on the js front. I'd really prefer if someone started a javascript SIG I could offload those to, I really don't have the cycles to progress quickly on packaging rules and tooling for two separate programming languages.
Regards,
-- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Le 2018-08-28 13:49, Jakub Cajka a écrit :
Hi Jakub
I could spend some time on most of those (though I'd rather pass on B, already done my part, and D/E would be the most fun and probably the most useful for the rest of the SIG).
For B I would much appreciate if you would mark which parts of your proposals got implemented and in which way. It would greatly help anyone picking this topic after you. If you really do not plan to finish all the work that you have started.
I'm pretty sure most of what's on the page is now done and can be used to package Go in Fedora (kudos to jchaloup who did a huge part of the work).
But sure, I'll make a pass to check if it contains references to stuff that turned out slightly differently than the initial plan
Regards,
golang@lists.fedoraproject.org
-
Jakub Cajka -
Neal Gompa -
Nicolas Mailhot -
Robert-André Mauchin