On 02/05/2017 03:10 AM, Hans de Goede wrote:
Hi All, So a lot has been said about $subject and FESco has asked me to send a mail to the devel list describing the what and why of this change.
There's two issues here that are important not to conflate: whether the glvnd update should go into f25, and the poor handling of the process of pushing it into f25 thus far. While I do have strong opinions on the latter point, I'll try to only address the former.
I don't think anyone will disagree with you that the libGL handling between mesa and third-party drivers is not great. Making the situation better is an admirable goal, and I'm glad there's work being done to improve things. However, changes as large as this run up against the stable update guidelines[1]:
"A major version number reflects a more-or-less stable set of features and functionality. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience."
This change definitely introduces features that materially affect the user experience, which means that it falls under the policy and requires an exception from FESCo *before* it can be considered for inclusion in f25. It seems we're in a place now where the new functionality is backed out and the unnecessary breakages have been addressed, so we can now take a step back and seek permission instead of rushing it out and asking for forgiveness.
The argument that someone blogged that this change would be maybe available in f25 so we should therefore push it into f25 is frankly not at all convincing in light of the above. A blog post doesn't override distribution policy, and doesn't exempt anyone from going through the processes to coordinate such a change with the rest of the project.
It's ultimately up to FESCo as to whether or not this change qualifies for an exemption. Personally, I think it doesn't. Pushing it into a release mid-stream seems overly aggressive to me when f26 is only 4 months away. Keeping the status quo in f25 for another 4 months won't be the end of the world - we've gotten this far with the sub-optimal libGL handling. If you really want f25 users to be able to test this change, you can maintain it in a copr and allow people to opt-in (and back out if there are issues.) Even if you do think the change is technically ready, it has only had a couple of weeks to settle and there may be other issues that testers haven't found yet.
In addition, I think a change of this magnitude should have really gone through the change process, not just announced on a blog that many of us don't read. The point of the change process is to provide a uniform way to let everyone developing the distribution know a big change is coming, provide a way for everyone to test against the change so they're not caught by surprise when e.g. sway and steam games stop working, and to provide a path to back out and regroup if the change has unforeseen consequences. In other words, to avoid exactly what happened here. The f26 system-wide proposal deadline was only a few days ago - there may still be time to write up and submit this as an f26 change if FESCo agrees to entertain it.
tl;dr: I say wait for f26 and go through the formal change process, but it's ultimately up to FESCo.
Rich [1] https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases [2] https://fedoraproject.org/wiki/Changes/Policy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
