Tracking Issue for workspace feature-unification

[ehuss]

Summary

RFC: #3692
Implementation: TODO
Documentation: TODO

Adds the resolver.feature-unification configuration option to control how features are unified across a workspace.

Unresolved Issues

• Bikeshed the config option naming.

Future Extensions

• Support in manifests
• Dependency version unification
• Unify features in other settings

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[weiznich]

Whoever marked my comment as duplicate: Could you point to the "duplicated" comment in this thread?

Also could you point to an official answer to these suggestions from the cargo team and not from individual team members? I'm really not sure what you are expecting to happen if you just keep pretending to ignore meaningful suggestions.

[epage]

As you said, this was repeating content from the RFC discussion. I gave some replies in the RFC. The Cargo team saw the discussion and signed off on the RFC without raising concerns. This was re-iterated by Eric in the thread you opened on Zulip, see https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Offical.20team.20response.20to.20concerns.20raised.20in.20RFC-3692/near/479039846

As this has come up before and is re-litigating the RFC, I collapsed it to get it out of the way of the discussion for implementing the RFC. It is a big help to be able to have Issue discussions more focused using tools like that. Some other teams go to the extreme of locking Tracking Issues, reserving them solely for status updates.

[weiznich]

@epage I still do not see where exactly my concerns about the potential social impact are addressed. Can you point to the exact location, including an explanation why it's not possible to have this slight adjustment to the wording to make clear that the communication around this feature needs to be aware of these edge cases. Given how other parts of the rust project usually try to have the best possible diagnostic for error cases I really cannot understand why you and the cargo team continues to just ignore these suggestions.

All I got so far is reiterating why you don't consider this a breaking change. I got your point there the first time, I just disagree with it. Even that does not mean that I'm the opinion that you shouldn't do this feature, which is why I literally trying to suggest for more than a month now that this likely can be resolved by just having that diagnostic/documentation note explicit in there.