Announcement

Collapse
No announcement yet.

Wine-Staging 3.4 Released With MS Office Anti-Aliased Fonts, BattlEye Fixes

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wine-Staging 3.4 Released With MS Office Anti-Aliased Fonts, BattlEye Fixes

    Phoronix: Wine-Staging 3.4 Released With MS Office Anti-Aliased Fonts, BattlEye Fixes

    Fresh off the release of Wine 3.4 on Friday, the maintainers corralling the Wine-Staging releases have now put out their second modern release...

    http://www.phoronix.com/scan.php?pag...g-3.4-Released

  • #2
    Typo:

    Originally posted by phoronix View Post
    Some of the fixes found in Wine-Staging 3.4 include supporting anti-alias fonts within Microsot Office,

    Comment


    • #3
      Does the BattlEye fixes mean games like PUBG should start to work in Wine now?

      Comment


      • #4
        Down to 1023 different to mainline. At this rate they will get under 1000 next release. The reality for longer term maintainability they have to get the number down.

        Its interesting watching how many are patched in staging in the wine bugzilla and after testing in staging there was never the final push to wine-devel mailing list for merge. Yes it works in staging I don't need to care is big part of the reason why staging has come so hard to maintain and why the current maintainers have a long job ahead of them cleaning out stuff that should have been merged sometimes years ago.

        Wine Staging is one heck of a clean up job. Once all the low hanging fruit of everything that should be merged then focus on cleaning up quality on what left can get serous.

        Comment


        • #5
          Don't forget sarnex ppa has Wine-staging with gallium-nine.

          https://launchpad.net/~commendsarnex...buntu/winedri3

          Comment


          • #6
            Originally posted by Dukenukemx View Post
            Don't forget sarnex ppa has Wine-staging with gallium-nine.

            https://launchpad.net/~commendsarnex...buntu/winedri3
            Has not done 3.4 mainline yet. Let alone up to 3.4 staging. History has seen a lot of different PPA come and go.

            Comment


            • #7
              Originally posted by oiaohm View Post

              Has not done 3.4 mainline yet. Let alone up to 3.4 staging. History has seen a lot of different PPA come and go.
              Takes him a while to get to it. He's been doing this for as long as Gallium-Nine was a thing.

              **EDIT**

              He just updated both to 3.4.
              Last edited by Dukenukemx; 03-18-2018, 12:30 PM.

              Comment


              • #8
                Originally posted by oiaohm View Post
                Down to 1023 different to mainline. At this rate they will get under 1000 next release. The reality for longer term maintainability they have to get the number down.
                In that case Qt needs to hurry up 'cause they have, as of writing, 8410 open bugs (not even counting In Progress bugs). That's even worse than wine-staging for longer term maintainability (your words, not mine).

                Comment


                • #9
                  Originally posted by Dukenukemx View Post
                  He just updated both to 3.4.
                  That the point you could have waited until he had done the 3.4 before redirecting people there. You find those running PPA sometimes skip versions of stuff when they run into trouble and he has done that before with wine with galluim-nine added version of wine. When a post is talking about X version of wine be responsible and only mention repositories that contain that at the time of posting so a person does not go to a repository expecting to find something and its 1 not there currently and 2 does not end up being a case of never there.

                  Originally posted by Vistaus View Post
                  In that case Qt needs to hurry up 'cause they have, as of writing, 8410 open bugs (not even counting In Progress bugs). That's even worse than wine-staging for longer term maintainability (your words, not mine).
                  Really you have just compared apples with oranges as the old saying goes. If there is something like a wine FIXME in Qt that has a matching bug entry in Qt in wine most of the FIXME entries don't have bug entries. Bugzilla in wine is used as a priority list not as a total defect list this is a big difference in usage. The total number known bugs in wine would be telly up the ERR/FIXME/STUBs as each one of them is a known defect then remove the overlapping bug .

                  STUBs that are known but not implemented functions yes known defect with 1,476 of them
                  FIXME that are known issues with functionality so defect there are 1,942 of them
                  WARN that are 981 and these are also known faults.
                  Majority of those don't have matching bug reports. In known defects wine project is over 10000. Unknown likely quite a lot more.

                  https://bugreports.qt.io/projects/QT...=allopenissues I do not know where you got 8410 open issues for Qt from there are over 16000 open issues. Compared to the known issues in wine and wine-staging that is a drop in the bucket.

                  The greater the delta in patches something has between the main project it syncing with the more likely an update will break it possibly in very hard to repair ways. Regression testing on the number of patches wine has between wine versions is hard enough with patch to patch interactions.

                  Also some of the reason why wine is so dangerous to patch on top of is the volume of FIXME that say this feature is not implemented and that feature be a far reaching functionality thing like the access controls in wined3d that once implemented that converted lot of performance hacks into fatal. Its not like all the fixmes with far reaching effects are fixed. Knowing the defects in wine says to have enough main power when its only 3 developers maintaining the patches and the far reaching FIXMES that are left to be fixed says they need to aim to be under a 500 commit difference not to have another ouch event of having to skip versions. Its a total man hours thing.

                  Wine mainline project has more developers so can cope with the higher load of release blocking defects. Qt project is fairly much the same more resources. Number of release blocking defects a project can successfully cope with and release on time is two factors. 1 man power 2 how short the release cycle is. Wine 2 week release cycle is down right hard. At over 1000 diff delta to mainline wine this has risk of more release blocking defect than the size team now supporting staging can cope with inside the release window.

                  Yes at 2.22 having 1 staging maintainer and release blockers that required a team of 3 4 weeks to deal with and a 2 week dead line to release that maintainer was serous-ally up the creek. Please note the worst release blockers was not fixed by the current staging maintainers but was fixed by upstream making a few of the defective patch pointless. Now know this you know that if the staging branch had not been lucky with upstream work they most likely would still be stuck in release blocker hell.

                  The 500 number say they need to get down to is based on knowledge of what size of patches is required so a 3 team can find a defective patch and have enough time in the 14 days to hopefully deal with release blockers.

                  Comment


                  • #10
                    Why I have to use the "-no-dwrite" to see menu/text in Steam and not with the wine-staging? Someone knows if dwrite is disable in wine-staging?

                    Comment

                    Working...
                    X