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. > > 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. >> 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 1. you know if the new API is compatible or not with other packages 2. you've saved human packagers the time and effort to do the same rebuild check manually So that's still a net win, no ? >> 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: 1. 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. >> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
