+1

+1

+1

I will abstain, since I submitted this proposal.

+1

+1

dumb question.. are there any drawbacks to this change? If not, why didn't we do this in the past?

Edited to remove superfluous (non counting) vote.

@dustymabe Please don't vote here (only current FESCo members vote), it's confusing when counting, thank you.

If you need to discuss this change proposal (your question is not dump, it's very good!), please do it in the devel mailing list thread.

@ignatenkobrain comment?

I'm somewhat -1.

• Current updates policy will not allow us without exception break compatibility of rust-*-devel packages.
• Yes, creating "compat" packages is not so much work but somebody will have to do it and it is additional burden.
• We still don't have any automation to handle multi-release builds so people who will be updating stack of packages will have to do it 3-4 times (with buildroot overrides and such).
• I don't see proposal mentioning any implementation of an automation, so IMO this is just a step back and not forward.

What I'm afraid of is that packages that are now can be (or are) updated on stable releases, people care of (ripgrep, zola and bunch of others) will be staying on the outdated versions because nobody will manage to update them.

If I compare current workflow (build on rawhide, run one trivial shell script to make package built for stable releases) with proposed workflow (build everything everywhere, creating compat packages if necessary, keep all build dependencies around just to keep compatibility 3-4 times just to make new version of some useful tool available in stable releases) - I'm still not convinced this is anyhow better. I'd prefer packagers to spend their time on something more useful, whether this is automation or improvement of this process or anything else.

This Change lowers the bar for contributing to the Rust stack in fedora, because it will no longer be a special case that involves additional steps.

I agree it is not ideal now, and I'd like people to improve this. Though not the way it is being proposed.

This Change will also make it easier and/or possible for Rust packages to comply with the terms of certain Licenses, e.g. the GPL, LGPL, or MPL.

I still do not understand how this is the case. Where is actually automation to determine final license of a binary? Yes, it exists and works for rawhide but this is about something else. Is it about RPMs? If so - all contents is available on the koji and anybody is able to reproduce any builds and so on.

IMO the Rust packaging needs more love but in the automation and not by tripling amount of work people need to do.

tl;dr. I'm against of this change since I think it is just adding more manual work without any gain. -1

Current updates policy will not allow us without exception break compatibility of rust-*-devel packages.

BTW I'd be happy to grant a general exception via this change process if needed.

BTW I'd be happy to grant a general exception via this change process if needed.

I'm actually surprised why there is nothing like that for Go. That'd be helpful, but won't solve the huge increase of manual work.

BTW I'd be happy to grant a general exception via this change process if needed.

I'm actually surprised why there is nothing like that for Go. That'd be helpful, but won't solve the huge increase of manual work.

Go doesn't need it, since version compatibility expectations are broader than SemVer (Go only supports semver-major as a compatibility promise).

Current updates policy will not allow us without exception break compatibility of rust-*-devel packages.

BTW I'd be happy to grant a general exception via this change process if needed.

Since the source-only rust-*-devel packages are only ever required and installed during RPM builds in mock (locally and in koji), and end users are not expected to install them, I think that's reasonable. I can include such an exception to the letter of the Update Guidelines in the Change proposal (which will probably trigger a re-vote, I guess?)

I can include such an exception to the letter of the Update Guidelines in the Change proposal (which will probably trigger a re-vote, I guess?)

I don't think so. This was already asked during the discussion on devel@ before the vote took place, and I agreed with the idea then. I think we're all fine with the idea.

The section about Update Workflow Changes in the Change Proposal details the expected update flow for source-only packages (which don't get installed by end users at all).

If it's necessary to ask for a "blanket exception" for such updates (since they don't strictly follow the Update Policy), even though they're not expected to be installed and/or used by users at all, I hereby ask for such an exception (only covering the source-only packages, but not Rust packages that ship binaries to end users) as part of this Change Proposal.

+1

https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-30/fesco.2020-09-30-14.00.html

let's give @ignatenkobrain a chance to discuss this next week

In today's meeting:

AGREED: FESCo approves the new Rust packaging approach and grants an exception to allow the backwards-incompatible -devel change. (+7, 0, -0)

Announced with meeting minutes.