----- Original Message ----- > From: "Nicolas Mailhot" <nicolas.mailhot@xxxxxxxxxxx> > To: golang@xxxxxxxxxxxxxxxxxxxxxxx > Cc: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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: > 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) 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
