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,
--
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
