----- 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
of Go based packages with compat names nobody cares about, instead of current 500 or so
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.