----- Original Message -----
From: "nicolas mailhot" nicolas.mailhot@laposte.net To: golang@lists.fedoraproject.org Cc: "Development discussions related to Fedora" devel@lists.fedoraproject.org, "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org Sent: Thursday, February 1, 2018 4:24:52 PM Subject: Re: <DKIM> [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging
De: "Jakub Cajka"
Filling upstream holes is pretty much the definition of an integrator/distributor role. In Go they are particularly numerous and deep, but Fedora users do want their docker and kubernetes (and Kubernetes, BTW, is astonishingly free of the problems that plague many Go projects, proving it *is* possible to do good release engineering in Go).
??
Just sending some kuddos Kubernetes-side. All the Kubernetes parts we had to work with so far were astonishingly free of API breakage and dependency cycles because Kubernetes people chose their deps carefully and do version their code states. It was a vacation from packaging other Go code.
Yes kubernetes is kind of better than most projects, but IMHO still uses lots of not so good practices, although getting bit better over the years.
Pain will not be eased in any significant way as you will still have to carefully evaluate every change so you don't break any dependent package.
Pain *will* be eased in a significant way because we will have the tooling to detect breakage automatically, and because fixes once they're done will be packaged and shared.
Your proposal doesn't provide this kind of tooling, if I'm not mistaken.
Not directly. It does provide the means to easily rev a spec to a new code state (version tag or commit), and it makes deps systematic (so Fedora tooling can accurately detect what is likely to be impacted by a change). Together, those open the way to use generic Fedora testing tools to automate build tests.
It makes it bit easier in some cases, but I wouldn't call it and revolution(as you are trying to sell it) rather than evolution(and omission of some currently mentioned parts), building on top of current practice.
If it's minor let's do it. I'm quite sure you will be pleasantly surprised by the level of pain those minor changes remove.
?? I'm in no way opposing your proposal per se.
Thank you
Fedora can detect the breakage which is the first step to fix it. It does not take an army of Go experts, just unbundled packages that can be rebuilt automatically to identify incompatibilities. Go experts are better employed working on fixes than doing rebuild checks that can be automated.
Rebuilds could be automated, analysis of them not easily.
Sure, but at that point
- you know if the new API is compatible or not with other packages
- you've saved human packagers the time and effort to do the same rebuild
check manually
So that's still a net win, no ?
No really, or not much, until you determine why the builds have failed(I can rebuild of whole distro each day, still I don't have enough spare time to determine and fix all FTBFS issues). You still have to have someone who would analyze those failures.
And nothing stops you for continuing to use those. Except, the golden test will always be to actually try to build the code, which is something that can be automated reliably once the dependencies exported to Fedora tools are themselves complete and reliable, and Go packages are exported as rpm packages, not hidden in private vendor trees.
?? I bit don't understand you. If you can, please help Jan to improve them.
What I meant is that:
- there are many ways to try to divine if a code state will build, but the
final arbiter is the Go compiler 2. to use Fedora-wide QA tools, code objects need to be exported as packages. Every missing test dependency, which is not packaged as a separate Go rpm, is something Fedora QA won't be able to run.
I think that I'm still missing your point. Of course you need to package all your dependencies.
When you do not unbundle you are still shipping the vendored code, you are still responsible for its bugs (security or not). Compat packages do not augment the code surface you have to care about, on the contrary they offer you the possibility to *reduce* the number of code states in the distribution.
Please don't put words in to my mouth. I haven't been talking about not un-bundling, just compat packages.
Sorry if I misunderstood you:(
However, I do think compat packages are a natural effect of unbundling. One does need something to fill in during the time upstream or Fedora work on the effects of an API break. Other Fedora language ecosystems do not manage to avoid them. You can strive to limit compat packages to the minimum amount, and the minimum period, but you can not fully avoid them, once an ecosystem has grown enough it is too big to be perfectly coordinated all the time.
So making compat creation easy and fast, is required to manage a huge amount of interdependent packages, which are not too careful about API stability. Even if one has little love for compat packages as such.
Regards,
-- Nicolas Mailhot _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-leave@lists.fedoraproject.org
I'm strongly against general unrestricted practice of compat packages as proposed. If you need compat package you need to work with usptreams on stabilizing the API/project, fork it, or just use COPR as your projects(or its dependencies) are not yet mature enough for Fedora.
JC