Announcement

Collapse
No announcement yet.

Flatpak 1.2 Likely Coming Around Year's End With New Features

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

  • #31
    Originally posted by Weasel View Post
    You obviously have no idea how the Wine development process works. Even as a user, you can always use the latest git version if you think it's too slow and just want the latest commits.
    I have done support for over 10 years. What you have said use to work. Has not for 7 years. Really you are clueless.

    There was a change over 7 years ago in the testbot when it stopped checking each individual git entry.
    http://test.winehq.org/data/
    Notice its doing a run every day most of the time. Sometimes you will have 2 runs per day and others no runs per day. The validation is checking patches in groups. Yes if you pull the latest git version this is not the latest version validated by testbot you risk getting a version with half a patch set applied.

    Yes you have people come into #winehq on freenode who have thought that could do what you said ask us about hey I built this master branch version of wine its not working right and we look at the testbot and patches applied and tell them hey it does work because what you have was taken in the middle of a patch set.

    So you do not with wine direct user to download latest git version. Instead you first direct them to a develop release that is that is about every 2 weeks or to a version that went well in testbot because you know those numbers are patch set complete.

    Now when you get projects without automatic CI like wine testbot and they are not doing releases and tell you to pull master from git is fairly much play a game of chance sooner or latter you will roll up half a patch set and want you downloaded fails to work correctly.

    Its not that hard to set a time frame to tag releases so you end users can download items all the time that are patch set complete.

    Users don't want the latest commits. Users want the latest point that works. Latest commits equals possible being half a patch-set so a program that does not work. Tagging releases is means to tell Users where the latest point that works is. If you are not doing a release you need list somewhere of git release numbers that are patchset complete then people packaging will use that as a release version number so you really did a release anyhow.

    Originally posted by Weasel View Post
    The only time that the release cycle does impact Wine development is when the major version is bumped (i.e. bumped Wine stable release, not just bugfixes) such as going from 3.x to Wine 4.x. For most contributors it otherwise doesn't matter whatsoever.
    There is a 2 week average release cycle on the development branch. It does have a clause that it can extend out to 4 weeks in case of major issue but there will be a release by 4 weeks.

    https://source.winehq.org/patches/
    Nothing like being a clueless wonder. Every 2 weeks roughly due to the rough 2-4 week development cycle the items on the patch que will be ticked off as accepted or answered as not accepted and why. Basically its like the Linux kernel 2 week merge window except it never closes except for the stable qa timeframe. So with the linux kernel roughly 90 days you get 2weeks to submit you patches and find out if they will be accepted or not.

    This is something you start seeing a lot. Large number of patches people work on and not submit until they can get an answer in 2 weeks if it will be acceptable or not.

    Stable release is a time wine project put aside every 12 months to stop and do more in depth quality control.

    The release cycle of wine has been designed to suit end users by giving them releases quickly also to maintain a fast cycle in patch processing.

    If you know you only have less than 14 days to approve something you make you choices quickly. If you know you have 12 months you suffer from procrastinate on making choice badly. 90 days of project leader procrastination or you worrying if they will accept you patch or not is bad enough. Shorter project leader procrastination time the better.

    Long release cycles have habit of letting project leaders suffer from procrastination and developers stressing over their patches as the project leaders do their procrastination over if this patch is good enough. Its a lot better with a short release cycle and get the pain over quickly.

    Really long release cycles don't help development and is not that helpful to end users having issues so in need of newer version.

    ABI stability and release cycles are two different things. There are ways of ensuring ABI stability and do a release every single day.

    There worst part about lead developer procrastination being allowed to run too long is by the time a person finds out that their patch is not accepted they can be working for another company that no longer wants them working on that patch. That patch could be a new feature or fix a security flaw.

    Comment


    • #32
      Originally posted by oiaohm View Post
      I have done support for over 10 years.
      I don't know what "support" means, but you realize I contribute to Wine, right?

      Originally posted by oiaohm View Post
      There was a change over 7 years ago in the testbot when it stopped checking each individual git entry.
      http://test.winehq.org/data/
      Notice its doing a run every day most of the time. Sometimes you will have 2 runs per day and others no runs per day. The validation is checking patches in groups. Yes if you pull the latest git version this is not the latest version validated by testbot you risk getting a version with half a patch set applied.
      What the fuck are you talking about?

      The testbot is just for tests. It doesn't impact the repository. And I'm pretty sure it's much more than "once per day" considering when I send a patch I get the results within 10 minutes at worst.

      "Half a patch" really dude smoke some more weed, computers don't work like voodoo, keep throwing random words like in movies, you are really fucking clueless. Alexandre wouldn't accept to commit only half a patch if it makes something "non-functional" in that state; he'd ask you to resend the entire patch series and commit all of it at once the next day (if it's not on weekend).


      Everything else you said is literally a wall of text full of bullshit from someone who literally does not understand any development process and talks like he knows the world.
      Last edited by Weasel; 11 October 2018, 07:47 AM.

      Comment


      • #33
        Originally posted by Weasel View Post
        "Half a patch" really dude smoke some more weed, computers don't work like voodoo, keep throwing random words like in movies, you are really fucking clueless. Alexandre wouldn't accept to commit only half a patch if it makes something "non-functional" in that state; he'd ask you to resend the entire patch series and commit all of it at once the next day (if it's not on weekend).
        http://test.winehq.org/data/
        Just look back to Sep 07. You see a massive increase in test failure. Comes back to normal levels on Sep 11. That is a time frame while part patch set is applied. The failure is that one of the patches of the patch set have been sent back by Alexandra for minor corrections. So the claim that Alexandre wouldn't accept to commit only half a patch if it makes something "non-functional" is bogus. Alexandre will not commit something that will make wine non functional if there is any risk that it will not be corrected before next release date. So while you are between releases Alexandre at his own judgement is allowed to break the functionality.

        Sorry Alexandre does apply half/part patch sets at times.. Generally about halfway though the release cycle. Basically it does pay to use the last version test by testbot showing sane test report issues. If there is spike you can fairly much bet there has been a patch sent back for minor corrections the test results will be back to normal before release.

        So Weasel you might have submitted patches to wine but you don't have a clue really what Alexandre will accept. Doing support in IRC to end users you get to know roughly when you have to be very careful with the wine master. Wine master is not always functional.

        Alexandre is more likely to accept part patch sets from developers he can trust to have the corrections done in short time frame.

        There is a difference between contributing code and doing end user support in what you know. I gave you hints where to look before commenting. I did mention notice that the testbot does not run every day. The days when the test bot is not running at all is when it point less because it known a part set is applied or Alexandre is not applying anything or testbot is broken.

        Yes there are clues when Alexandre has intentionally broken master branch of wine.

        Alexandre being hard on you demanding quality patches before merging them shows:
        1 the patches you are doing are minor.
        2 He don't trust you that if he let you slide that you would deliver before the next release.
        Its one of those two options.

        You have incorrectly presume that Alexandre merge rules are black and white. There are shades of grey but its really had to get the shades of grey most developers get black and white. Only highly trusted developers on delivery on time get the grey applies. Doing user support and the people who get the idea of build from master getting broken made me aware of the shades of grey.


        Comment


        • #34
          Originally posted by oiaohm View Post
          http://test.winehq.org/data/
          Just look back to Sep 07. You see a massive increase in test failure. Comes back to normal levels on Sep 11. That is a time frame while part patch set is applied. The failure is that one of the patches of the patch set have been sent back by Alexandra for minor corrections. So the claim that Alexandre wouldn't accept to commit only half a patch if it makes something "non-functional" is bogus. Alexandre will not commit something that will make wine non functional if there is any risk that it will not be corrected before next release date. So while you are between releases Alexandre at his own judgement is allowed to break the functionality.
          He always tests the patch on his own machines before committing, even if the testbot succeeds on all of the VMs.

          At this point I'm pretty sure you have no idea what the conformance tests are. Stuff doesn't break magically or randomly without changing anything. They break when patches get applied, and that's exactly when the testbot will apply tests automatically for each patch. If a test breaks on Windows, then the test itself is wrong and needs to be rewritten (not anything in Wine, this literally doesn't impact Wine at all).

          You can keep track of it here: http://source.winehq.org/patches/

          Note how EACH PATCH has an associated testbot results on the right which gets run within 10 minutes of you sending the patch. Click on the Job ID for more data and detailed information about which tests failed or not. So if a patch breaks a test, everyone would know immediately. ffs.

          The testbot even emails you (the patch sender) with the testbot results (privately), and if any tests fail whatsoever in it, then the email is sent publicly for others to discuss.

          Originally posted by oiaohm View Post
          Sorry Alexandre does apply half/part patch sets at times.
          Prove it.

          As for your rest: the testbot even runs on weekend. I seriously have no idea what you're smoking. It may sometimes be in maintenance but that's rare and not some time-based normal occurrence.

          Originally posted by oiaohm View Post
          Alexandre being hard on you demanding quality patches before merging them shows:
          1 the patches you are doing are minor.
          2 He don't trust you that if he let you slide that you would deliver before the next release.
          Its one of those two options.
          It's the complete opposite. Minor patches get merged in much faster, sometimes without even requiring a reviewer. But go on with it, it's hilarious.

          Originally posted by oiaohm View Post
          You have incorrectly presume that Alexandre merge rules are black and white.
          In respect to tests, which was YOUR point, then yes it's pretty much black & white. There's nothing subjective about "test failure" or "breaks tests". It's a measurable fact.
          Last edited by Weasel; 12 October 2018, 08:13 AM.

          Comment


          • #35
            Originally posted by Weasel View Post
            He always tests the patch on his own machines before committing, even if the testbot succeeds on all of the VMs.
            True this means he knows when it fail. This does not mean he will not submit the patches to master when there are know failures. Some major changes need to go into master so that people can re-base their patches correctly even if they break wine ability to run programs for a short time.

            Originally posted by Weasel View Post
            You can keep track of it here: http://source.winehq.org/patches/
            That is testing when you submit patches. Not testing on the master branch.

            Originally posted by Weasel View Post
            Note how EACH PATCH has an associated testbot results on the right which gets run within 10 minutes of you sending the patch. Click on the Job ID for more data and detailed information about which tests failed or not. So if a patch breaks a test, everyone would know immediately. ffs.
            Note what you said each patch. There are some that on patches page fail because testbot has not put like the set of 8 patches together.

            Originally posted by Weasel View Post
            The testbot even emails you (the patch sender) with the testbot results (privately), and if any tests fail whatsoever in it, then the email is sent publicly for others to discuss.
            This is not a master branch test.

            Originally posted by Weasel View Post
            Prove it.
            i all ready gave you when to look at Sep 6-7 you will is a patch set some of the patches passed testbot but there was a formating issue in a few patches. Yes those had been sent back by Alexandre for fix. The fixed version went in Sep 10.

            Originally posted by Weasel View Post
            As for your rest: the testbot even runs on weekend. I seriously have no idea what you're smoking. It may sometimes be in maintenance but that's rare and not some time-based normal occurrence.
            Not against the master branch. Testbot use to run on every patch applied to master branch has not done that for 7+ years.

            7+ years ago testbot moved to testing every submit patch this was to provide developer with faster feed back on issues. Processing power had to come from somewhere. The processing power came from reducing the frequency of master branch testing.

            Also the other thing is that wine master branch prime users is meant to be developers. So break wine master branch ability to run applications is acceptable as long as this is for a major patch what other patches have to rebase on top of and that the rebasing can be done before next release.

            Originally posted by Weasel View Post
            In respect to tests, which was YOUR point, then yes it's pretty much black & white. There's nothing subjective about "test failure" or "breaks tests". It's a measurable fact.
            The shades of grey comes in if those test failures are valid to stop the patch merges. Structure changes can see a few hundred tests fail until the complete set of patches is applied.

            Alexandre is the only one who can make a judgement call to ignore test failures.

            As I said there is a big difference between a person being a developer submitting code to being a person supporting end users. As a person supporting end users I have to deal with the case when user decide to pull from git master in a time frame when Alexandre has decided to break the master. The sections where there has been one of these breaks is fun when a git bisect runs into it. Testbot runs against master can be very important when bisect problem.

            Comment


            • #36
              Originally posted by oiaohm View Post
              True this means he knows when it fail. This does not mean he will not submit the patches to master when there are know failures. Some major changes need to go into master so that people can re-base their patches correctly even if they break wine ability to run programs for a short time.
              Actually, he will, and the patch will be marked as "Test Failure". If you bothered to look at the link I gave you, you'll understand this as well. So, how about you prove it?

              Originally posted by oiaohm View Post
              That is testing when you submit patches. Not testing on the master branch.
              You can't be so stupid, seriously? The testbot runs against the master branch. WTF are you even throwing random words around like a clueless wonder.

              This is a proof because otherwise it would fail to build, when you send a patch that depends on a previously committed patch in less than an hour. Idiot.

              Originally posted by oiaohm View Post
              Note what you said each patch. There are some that on patches page fail because testbot has not put like the set of 8 patches together.
              That's a bug in the testbot, and in that case they are examined manually. Which happens rarely, mind you, and the subject was about time-based releases which are a normal occurrence not "exceptional", so again you switch subjects because you're out of arguments.

              Originally posted by oiaohm View Post
              This is not a master branch test.
              Bullshit. I'm sick of your claims. Prove it.

              Originally posted by oiaohm View Post
              i all ready gave you when to look at Sep 6-7 you will is a patch set some of the patches passed testbot but there was a formating issue in a few patches. Yes those had been sent back by Alexandre for fix. The fixed version went in Sep 10.
              Formatting patches are completely harmless so yes he can skip those, YOU WERE TALKING ABOUT THE TESTBOT. Adding whitespace or wrong comments or other formatting issues does not impact the behavior of Wine in the least so it's harmless. Stop switching subjects when you run out of arguments.

              You always bring BULLSHIT UP, like the "test failures", I prove it wrong, then you switch and "prove" something else totally unrelated (like formatting). Just shut the fuck up already with your misinformation on this forum.

              Originally posted by oiaohm View Post
              Not against the master branch. Testbot use to run on every patch applied to master branch has not done that for 7+ years.

              7+ years ago testbot moved to testing every submit patch this was to provide developer with faster feed back on issues. Processing power had to come from somewhere. The processing power came from reducing the frequency of master branch testing.

              Also the other thing is that wine master branch prime users is meant to be developers. So break wine master branch ability to run applications is acceptable as long as this is for a major patch what other patches have to rebase on top of and that the rebasing can be done before next release.
              Again, prove it.

              There's a tag called Apply failure and guess what? One of the reasons is: It's not relative to the latest git.

              Originally posted by oiaohm View Post
              The shades of grey comes in if those test failures are valid to stop the patch merges. Structure changes can see a few hundred tests fail until the complete set of patches is applied.

              Alexandre is the only one who can make a judgement call to ignore test failures.
              Because it means the test failures are harmless. "Structure changes" please use more mumbo jumbo words from a true programming illiterate.

              It feels like I argue with those "hackers" from movies.

              Comment


              • #37
                Originally posted by Weasel View Post
                Actually, he will, and the patch will be marked as "Test Failure". If you bothered to look at the link I gave you, you'll understand this as well. So, how about you prove it?

                You can't be so stupid, seriously? The testbot runs against the master branch.
                Sorry speak to alex some time. Learn that its not run against every patch to master branch these days. Testbot is run against master branch when it has been requested to-do so.

                Comment


                • #38
                  Originally posted by oiaohm View Post
                  Sorry speak to alex some time. Learn that its not run against every patch to master branch these days. Testbot is run against master branch when it has been requested to-do so.
                  Yea of course you talk to him and I don't... not even sure what I'm supposed to say here at this wonderful cop out, it's like arguing in kindergarten.

                  You don't even have to think very hard to realize that it must be on the "master branch", otherwise patches would fail to apply in the testbot. There's literally no reason for it to not be updated to the master branch, when even their github mirror is.

                  You also lack basic understanding how a version control system works, like git, claiming crap like "half patches" when a linear history makes your claims so stupid and impossible -- literally. But I digress. Pointless arguing with willful ignorants.

                  You seem to have this misconception that committing patches to the "master branch" needs massive amount of resources on the testbot (or any computer). You realize this takes milliseconds, right? Even rebasing off the origin (latest git) is fractions of a second if you do it daily.

                  (and btw, you're mixing git terms up, the "master branch" is your local repo, it's not the remote repo, but I know that's what you meant, I hope? origin is the remote repo, and origin/master is its master branch)
                  Last edited by Weasel; 13 October 2018, 07:01 PM.

                  Comment


                  • #39
                    Originally posted by Weasel View Post
                    Yea of course you talk to him and I don't... not even sure what I'm supposed to say here at this wonderful cop out, it's like arguing in kindergarten.

                    You don't even have to think very hard to realize that it must be on the "master branch", otherwise patches would fail to apply in the testbot.
                    This is also why in patches.winehq.org you see some patches first be reported as failed by Testbot then latter you see them change to ok with a job number that appears out of order with those around it. Yes the rare case of something needing a new version to apply patch. Patches to fail to apply and the testbot tries the patch again latter this only happens because it faster this way on average.. So yes patches do sometimes fail to apply due to the version difference. But its less than 1 in 2000 patches. So roughly inside 24 hours of master is good enough for testbot.

                    Originally posted by Weasel View Post
                    There's literally no reason for it to not be updated to the master branch, when even their github mirror is.
                    There is a very good reason why testbot is not using latest master branch. You patch is tested on the last version of master to have a full audit run against. So that there is data to compare what defects wine had to what defects you patch creates/removes. There is 300-400 known issues in each wine version that the testbot testing will find.

                    This is you being wrong as normal. https://testbot.winehq.org/JobDetail...&f101=log#k101 have you not been reading you patch reports.

                    Testbot is not in fact using master branch most of the time. The head value is set back in the test reports.
                    If you check your head numbers you will find that they are listed
                    http://test.winehq.org/data/ <right here.

                    So if you want to see what will be the most likely version that you patch you have just sent in will be tested against you go to http://test.winehq.org/data/.

                    Having the number that master is at is not going to be that much help. Yes optimisation to test faster does add a few bugs.

                    Really Weasel I am only have to tell you this because you are being a idiot presuming stuff instead of reading the reports you are sent back and taking note of what it told you it was using. You would have noticed the miss alignment between master and what the testbot is in fact using.


                    Comment


                    • #40
                      Originally posted by oiaohm View Post
                      This is also why in patches.winehq.org you see some patches first be reported as failed by Testbot then latter you see them change to ok with a job number that appears out of order with those around it. Yes the rare case of something needing a new version to apply patch. Patches to fail to apply and the testbot tries the patch again latter this only happens because it faster this way on average.. So yes patches do sometimes fail to apply due to the version difference. But its less than 1 in 2000 patches. So roughly inside 24 hours of master is good enough for testbot.
                      No they end up as failed because those are pre-existing failures, or failures on a tiny subset of Windows versions. If you look at the jobs report you see it's usually 64-bit Chinese Vista with broken behavior, which nobody really cares much about.

                      Originally posted by oiaohm View Post
                      There is a very good reason why testbot is not using latest master branch. You patch is tested on the last version of master to have a full audit run against. So that there is data to compare what defects wine had to what defects you patch creates/removes. There is 300-400 known issues in each wine version that the testbot testing will find.
                      Again, you clearly have no idea what a conformance test is.

                      Originally posted by oiaohm View Post
                      This is you being wrong as normal. https://testbot.winehq.org/JobDetail...&f101=log#k101 have you not been reading you patch reports.

                      Testbot is not in fact using master branch most of the time. The head value is set back in the test reports.
                      If you check your head numbers you will find that they are listed
                      http://test.winehq.org/data/ <right here.
                      ...what are you talking about? The head is always the commit. In the job report you linked, that's the 3.18 release, see (just add the head's hash at the end): https://source.winehq.org/git/wine.g...6f7526b994fa93

                      That's the latest push to the repository, so in fact it IS your so-called "master branch".

                      What the fuck are you even talking about?!? I don't even know, but let me guess and take a shot based on your cluelessness. You are wondering why a single patch doesn't INSTANTLY update the master, aren't you?

                      A patch gets committed to the remote repo only when it is approved and Alexandre commits it there. Typically, you get these every day at night european time.

                      Obviously, the testbot runs against the REMOTE REPO, not against ALL pending patches. That's just LOGIC because a patch could be REJECTED and then you end up with test results that make no sense. You think patches get instantly committed on the "master branch", which is just retarded, why even send patches then? Just have everyone get access to commit there.

                      That's why patches sent in a series (1/x, 2/x, 3/x, ...) are applied all at once: they're all relative to the remote repo, and applied together so they can depend on each other.

                      Really you're so clueless it's embarrassing to explain basics to you.

                      If you look at your stupid test result page you love so much you realize the "master" is updated daily when Alexandre commits patches (or rejects them), except on weekends or when he's on vacation or whatever other exceptions. Look at the dates. He's the only one with commit access so you can't have it any other way.

                      If you are working on multiple patches that depend on each other you send them all as a series at once as I explained. But you don't have to care about the wine release schedule most of the time (except when the major version is bumped).

                      Now I feel like I wasted time explaining basics to someone who obviously will ignore it on purpose.

                      Comment

                      Working...
                      X