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

[Weasel]

Except this is not true on the once per day bit.
http://test.winehq.org/data/ note Oct 03 and you can find other days where he has done that 3 to 4 times back though history. Alexandre push batches of patches to the master branch. Then decides if he wants the testbot to run over those patches before sending next batch. This is why you need to check head value against what testbot is tell you it tested with. It is possible that you have pulled from wine master while Alexandre is updating it and have pulled halfway though the application of patches.

How many times must I tell you that page is just overview. As a developer, you get your testbot run when you send the patch, against the current "master branch". When you go git clone, you get the "master branch", and that's what the testbot runs against (after it applies your patch series, obviously). It doesn't matter how often Alexander pushes the patches to the "master branch" (yes in batch, I never claimed otherwise). What has that to do with the release schedule?!? Please.

This is not true. Testbot runs with what ever branch Alexandre has told it to. This happens at times when there is a branch breakage that will be fixed by a latter patch at times as well.

The historic version of wine testbot use to only test patches after they were applied to master as a commit as it job was to detect master branch breakage. Altering around to testing patches before application does make sense. The big mistake you are making is thinking Alexandre updates master branch all the time as one big update. You will get caught pulling wine master branch from time to time and not checking the master head value against what testbot is showing because you will have pulled mid application of patches by Alexandre when he was considering if he was going to run testbot more than once that day. Yes he can change mind on that but if you have pull wine master and have not checked you end up being the one who sends in patches that come up with failed patch application because you have a branch mid update.

Yes mid update can be human error on Alexandre part where he has noticed I sent up that patch bundle missed a key patch. This is why it pays to have a master branch and a second area you update when everything else doubled checked. Gives a chance for those who know the system to see when human error has happened on master and avoid sending up invalid patch files and avoid attempting to build known broken by maintainer.

So master branch value of wine and what testbot is using is not 100 percent synced and it makes sense for it not to be and it Alexandre who sets sync he is not just in charge of master branch he has particular controls over the testing system..

Basically there is a form of race condition that can happen with the wine master branch. People do manage to find it.

K, I've no idea what I read honestly. And I don't think you understand what a race condition is, either. If something is either updated or not updated, that's not a race condition.

It's only when it is partly updated, and I guess you need to supply some proof for that case. Cause I've never seen it happen yet.

Anyway, we're going off on a large tanget (like usual). What has this to do with the release schedule, again? You really love arguing about anything.

[oiaohm]

AFAIK only Alexandre has commit rights to the "master branch" so sending in a patch means nothing until he accepts it, which he does once per day except on weekend.

Except this is not true on the once per day bit.
http://test.winehq.org/data/ note Oct 03 and you can find other days where he has done that 3 to 4 times back though history. Alexandre push batches of patches to the master branch. Then decides if he wants the testbot to run over those patches before sending next batch. This is why you need to check head value against what testbot is tell you it tested with. It is possible that you have pulled from wine master while Alexandre is updating it and have pulled halfway though the application of patches.

The testbot always runs against the "master branch".

This is not true. Testbot runs with what ever branch Alexandre has told it to. This happens at times when there is a branch breakage that will be fixed by a latter patch at times as well.

The historic version of wine testbot use to only test patches after they were applied to master as a commit as it job was to detect master branch breakage. Altering around to testing patches before application does make sense. The big mistake you are making is thinking Alexandre updates master branch all the time as one big update. You will get caught pulling wine master branch from time to time and not checking the master head value against what testbot is showing because you will have pulled mid application of patches by Alexandre when he was considering if he was going to run testbot more than once that day. Yes he can change mind on that but if you have pull wine master and have not checked you end up being the one who sends in patches that come up with failed patch application because you have a branch mid update.

Yes mid update can be human error on Alexandre part where he has noticed I sent up that patch bundle missed a key patch. This is why it pays to have a master branch and a second area you update when everything else doubled checked. Gives a chance for those who know the system to see when human error has happened on master and avoid sending up invalid patch files and avoid attempting to build known broken by maintainer.

So master branch value of wine and what testbot is using is not 100 percent synced and it makes sense for it not to be and it Alexandre who sets sync he is not just in charge of master branch he has particular controls over the testing system..

Basically there is a form of race condition that can happen with the wine master branch. People do manage to find it.

https://source.winehq.org/git/wine.g...s/heads/master
if you get here quick enough you will see a303f9cd101a to 3f4455c0f043650151873d899e6f7526b994fa93 (3.18)
You will notice that Alexandre sent the patches to master in 3 batches. If you catch the master mid Alexandre update of master you can be in trouble. Lot of sends to master are single batches but there are these big ones what can see master in git out of alignment with version testbot is using for quite a few hours.

Yes even that was 3 batches of patches to master the testbot is only touching the last one. So testbot and wine master is mostly aligned. But like in this recent case there was a 10 hour window when it was not. This are cases where I end up with people building from git master sometimes coming into #winehq on freenode asking what problem is.

This is why I tell those pulling from wine master to check version they have against testbot if it not matching the latest version on testbot wait a little bit. Under 12 hours it should get a testbot listed point.

Weasel what is the luck of it the problem I have been talking about about master going out of alignment with what testbot is using just happens to do it when we are talking about it. Its not exactly luck it in fact happens quite often. Maybe when you pull is mostly when Alexandre is not at work.

[Weasel]

New post because last one had to be approved so you prolly didn't get notifications.

Short version: The testbot always runs against the "master branch". The "master branch" is what you get when you use git clone. Patches are NOT COMMITS, they do NOT become part of the master branch until they are committed (by Alexandre).

So just because you sent a patch, which did not get committed yet, and you sent another patch and the testbot used the "master branch" WITHOUT your first patch, does NOT mean the testbot doesn't run against the "master branch". Your confusion stems from the fact that you think patches sent in automatically update the "master branch" but that's retarded -- why would they even be patches then, just make them commits.

AFAIK only Alexandre has commit rights to the "master branch" so sending in a patch means nothing until he accepts it, which he does once per day except on weekend, and that is WHEN the "master branch" gets updated. Uncommitted patches are NOT part of the "master branch".


Speaking of which, no user has access to uncommitted patches even if they download the "master branch", unless they apply the patches themselves.

[Weasel]

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.

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.

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.

[oiaohm]

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.

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.

[Weasel]

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)

[oiaohm]

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.

[Weasel]

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?

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.

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.

This is not a master branch test.

Bullshit. I'm sick of your claims. 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.

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.

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.

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.

[oiaohm]

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.

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.

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.

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.

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.

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.

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.

[Weasel]

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.

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.

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.

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.