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