----- Original Message ----- > From: "nicolas mailhot" <nicolas.mailhot@xxxxxxxxxxx> > To: golang@xxxxxxxxxxxxxxxxxxxxxxx > Cc: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>, "Discussion of RPM packaging > standards and practices for Fedora" <packaging@xxxxxxxxxxxxxxxxxxxxxxx> > 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 > 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 ? 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: > 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. 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to golang-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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 _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
