----- Mail original ----- De: "Jakub Cajka" > I think one of the main responsibilities of Fedora packager is to work with upstreams, help them > mature and generally improve their projects. Sure but expecting everything to be perfect and consistent before shipping anything just DOES NOT WORK. Reality is not black and white, it's messy with shades of gray Even the C/C++ guys do not manage to ship a compat-free package ecosystem, and their projects had a few more decades than Go projects to mature, and rpm was pretty much built around C/C++ expectations. Compat packages are a fact of life in any large software ecosystem, where you can't achieve perfect cohesion. Go is getting *very* large. It needs compat packages. That does not mean there will be hundreds of them because, creating packages is *work*, that does not need they will need maintaining for years, because the aim of each compat package is to get obsoleted as fast as possible, but there will always be some of them at any given time. We are not building a cathedral. Bazaars are messy when full of life. > Do you have any evidence supporting this claim? From my point of view Jan and other packages has > been spending lot of time on on boarding packagers and working on tooling. No one (and certainly not me) is accusing you or Jan not to spend a crazy amount of time and energy trying to make things work. But you did not achieve a satisfactory Go state in Fedora, read again what Owen wrote, I didn't put any word in his mouth, even though I could have written pretty much the same message a few months ago. Again, no one (and certainly not me) disputes your level of dedication to the "cause". You just made some choices in the past (trying to avoid working within rpm via godep, refusing to include different states of the same Go code in the distro when major Go apps *disagree* on the correct state to include) that didn't work out in practice, with the hindsight of several years of Fedora Go packaging and the Go package state achieved in Fedora after those years. It's time to adjust those choices a bit. > From my perspective distribution will end up with crazy amount of bitrotting, backport, constant > attention requiring package crud..., IMHO basically same as now, apart of it we will have few 1000s > of Go based packages with compat names nobody cares about, instead of current 500 or so packages. Fedora has lots of Go packages no one cares about because they do not permit building the apps people *do* care about. Building the apps people care about requires a more aggressive update policy, and accepting people will work in parallel on apps, that demand different code states, of common dependencies. And there are not so many of those, I count 18 of them in our repo out of 476 Go packages, even though the work is not completely finished, and finalizing the build of complex tip apps is almost certain to increase the proportion a little. That's awfully *good* and *nice* given the "no Go API compatibility" scarecrows people like to invoke. You won't *ever* attract a large pool of packagers, to work on a package baseline, that will eventually in some years permit building apps, but never this year, because upstream state is not conflict and compat-free yet. Regards, -- Nicolas Mailhot _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
