----- 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: Saturday, February 3, 2018 4:27:36 PM > Subject: Re: <DKIM> [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging > > > De: "Jakub Cajka" > > Hi Jakub > > > 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. > > I appreciate the sentiment, and I quite hate compat packages, but the > restrictions you want did not work in practice for Fedora. > > Making compat package creation hard does not result in faster fixing to use > new code. What it actually does is to block the packaging of all the > projects that need a more recent package state, because packagers that need > the old state for one of their packages, will drag their feet on updating > common dependencies till the code of their packages is fixed upstream, or > they have the time to fix it themselves. > I think one of the main responsibilities of Fedora packager is to work with upstreams, help them mature and generally improve their projects. > And blocking packaging of new part means you do not get the new packagers > that would join because they're interested in the new parts, and would > contribute to the maintenance of common deps (not all of which need > compat-ing), and would relieve part of the pressure on the existing > packagers, that prevents them from working as much a they'd like to on > updating their packages. It's a death spiral. It results in a massively > obsolete Go package baselines, full of holes, because all the energy is > poured in making existing stuff work, at the expense of onboarding new > packages and packagers. > > Regards, > > -- > Nicolas Mailhot > _______________________________________________ > golang mailing list -- golang@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to golang-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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. >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. JC _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
