Wine-Staging has been forked

[rboxeur]

Original developers stopped to maintain the original repo. Wish you the best guys in your new life

Some Wine Developers try to maintain it now

https://github.com/wine-staging/wine-staging

[lahmbi5678]

I think, it's a full time job to keep a project like wine-staging alive and up2date, so maybe Codeweavers should sponsor at least one developer to do it. Afaiu Alexandre&Co weren't too excited, when wine-staging came up, but now they appreciate it as kind of test environment. In the long run, wine and Codeweavers will benefit immensely from having a playground to test new patches and approaches in the wild.

[dimesio]

I think, it's a full time job to keep a project like wine-staging alive and up2date,

I agree. I also think developer time is better spent working on improving the staging patches and getting them into the main branch than on maintaining a separate branch. But it's up to the developers to decide how they want to spend their time.

[Bob Wya]

I think, it's a full time job to keep a project like wine-staging alive and up2date,

I agree. I also think developer time is better spent working on improving the staging patches and getting them into the main branch than on maintaining a separate branch. But it's up to the developers to decide how they want to spend their time.

Also I see it's already gone of the rails...
With Slackner I could always build the Wine Staging Git Master - referencing the Upstream Wine Git Commit.

The fork of Wine Staging is all over the place now... Q/A has gone down the toilet...
The forked version has been pointed far too far forwards - in the Upstream Wine Git tree...
But without updating and rebasing the Staging patches first...
So now Staging patches literally fail to apply now - which should never happen.

Staging versioning, copyright assignment, etc. - also a mess - getting updated at (seemly) random by different people...

Bob

[ObsequiousNewt]

I think, it's a full time job to keep a project like wine-staging alive and up2date,

I agree. I also think developer time is better spent working on improving the staging patches and getting them into the main branch than on maintaining a separate branch. But it's up to the developers to decide how they want to spend their time.

Also I see it's already gone of the rails...
With Slackner I could always build the Wine Staging Git Master - referencing the Upstream Wine Git Commit.

The fork of Wine Staging is all over the place now... Q/A has gone down the toilet...
The forked version has been pointed far too far forwards - in the Upstream Wine Git tree...
But without updating and rebasing the Staging patches first...
So now Staging patches literally fail to apply now - which should never happen.

Staging versioning, copyright assignment, etc. - also a mess - getting updated at (seemly) random by different people...

Bob

Yes, it's currently in a rather disordered state. We're working on fixing the broken patches as quickly as we can.

Please keep in mind that we aren't quite used to the staging build system, so some things such as versioning may also be temporarily broken as well.

[Bob Wya]

Yes, it's currently in a rather disordered state. We're working on fixing the broken patches as quickly as we can.

I know it's easy to criticise on the sidelines... But that seems to be what the Internet is for these days...

But, but, but anyway...

1. Wine Staging was more than just the Github respository. It was the automatic package build service - for multiple distributions. The website, etc.
2. Regressing back to the state where the Wine Project cannot officially recognise it - seriously depreciates the value that the Wine Staging fork serves.
3. In recent months Slackner was the only person who rebased and refactored the patches. Having more than one person do this simultaneously is a really big mistake!
   Slackner would rebase all the patches in small steps, in a Git clone, and only push the changes in a block of commits when they were build tested (i.e. not just checking that the patches applied)...
   The "new project" seems to be doing things backwards - moving the Upstream commit forwards - then (hopefully) fixing the patches afterwards...
4. People who are totally unfamiliar with really basic recent Wine changes are pushing changes to the forked Wine Staging repository... This a not a recipe for a successful project!

I did think about a clean way of rebasing the Wine Staging patchset... Because it's annoying when someone spouts opinions without offering an alernative!

The factoring would be best done stepping in a semi automated fashion.

1. Stepping through the Wine Git tree, commit by commit, with an automated BASH / Python script building Wine Staging against the Wine commit every time the Git patch author changes (as Wine patches are typically committed in blocks by individual developers).
2. Then you rebase individual Wine Staging patchsets as they break and redirect the Wine Staging patch installer script at the Upstream commit at this point.
3. By doing this, in stages, you can easily see when Wine Staging patchsets have been superseded by Upstream developments (because you have the exact commit of breakage).
4. This process would have to be done starting at the vanilla Wine 2.21 Git commit and step through commits from all subsequent releases: 2.22, 3.0-rc*, 3.0, 3.1, 3.2...

What you doing is effectively time-travelling 100 years into the future and trying to use the technology of that day without any context of how things work in that time!

I would do the work myself - but I'm not sure that Wine Staging has much value any more... Since it is no longer officially recognised by the Wine Project.

Bob

[dimesio]

I would do the work myself - but I'm not sure that Wine Staging has much value any more... Since it is no longer officially recognised by the Wine Project.

If you're referring to the staging checkbox on the AppDB test form, that was disabled for new reports because at present there are no valid staging releases past 2.21, but users were checking it for versions that don't exist in staging. If and when there are up-to-date staging releases with official WineHQ packages, I will re-enable the checkbox.

[ObsequiousNewt]

Yes, it's currently in a rather disordered state. We're working on fixing the broken patches as quickly as we can.

I know it's easy to criticise on the sidelines... But that seems to be what the Internet is for these days...

But, but, but anyway...

1. Wine Staging was more than just the Github respository. It was the automatic package build service - for multiple distributions. The website, etc.

Yes, and those are/were owned and maintained by slackner et al. We haven't worked out yet how our build infrastructure is going to work; we've been currently working on fixing patches.

[*]Regressing back to the state where the Wine Project cannot officially recognise it - seriously depreciates the value that the Wine Staging fork serves.

I'm not entirely sure where you're getting this. dimesio has removed the staging checkbox from AppDB reports, but as she said, that's because there have been no staging releases to test under. Presumably that will be restored once we continue to make staging releases. Alexandre has only said that "we'll need to discuss how to move forward".

[*]In recent months Slackner was the only person who rebased and refactored the patches. Having more than one person do this simultaneously is a really big mistake!
Slackner would rebase all the patches in small steps, in a Git clone, and only push the changes in a block of commits when they were build tested (i.e. not just checking that the patches applied)...
The "new project" seems to be doing things backwards - moving the Upstream commit forwards - then (hopefully) fixing the patches afterwards...

While I can understand the perception, in reality this isn't really the hurdle to changing patches. Wine 3.2 isn't æons ahead of Wine 2.21, and the progress which has been made is spread across a large set of areas, most of which Staging doesn't even touch. Most patches which are broken have only been broken by one set of commits, not incrementally broken by multiple sets. The reasons it's taking so long are rather that there's a lot of patches which were broken, and we still acquainting ourselves with the Staging repository infrastructure.

Believe it or not, having multiple people working together actually helps quite a lot, since there's a lot of work to be done and we are busy people. And believe it or not, we are coördinating our efforts. The last thing any of us want is to duplicate any work

[ObsequiousNewt]

I think, it's a full time job to keep a project like wine-staging alive and up2date,

I agree. I also think developer time is better spent working on improving the staging patches and getting them into the main branch than on maintaining a separate branch. But it's up to the developers to decide how they want to spend their time.

I agree in principle, and I intend to spend some effort on upstreaming (or removing) some of the patches in the staging tree. That said, an unfortunately large number of users depend on Staging, and it would quite be a shame to leave them stranded. And it's also true that the climate of wine-devel—though it has been asserted that it is better than it used to be—is still less than friendly (and far less than helpful) to new developers, and so this second purpose of staging should still be served if at all possible.

[froschmaterial]

The fundamental issue seems to be that there is no one on the wine team who walks staging patches through the adoption process and if feedback on submitted patches was given it is lost.

KDE uses reviewboard, also with github we have a nice process to discuss and autoreview patches.

Say, if there are issues with coding style it makes sense to run automated tests that check if a certain c standard is complied with or a certain coding style.

But basically the issue is that Wine-Staging includes patches that helped a user to resolve issues but no proper recorded feedback is available why they were not accepted in the main tree and how to improve them further so they would. So you don't know for which arbitrary argument they were not included and what the suggested proper way to fix the issue would be.

If the patch review process would work conveniently for contributors there would be no need for Wine staging to begin with.

[dimesio]

But basically the issue is that Wine-Staging includes patches that helped a user to resolve issues but no proper recorded feedback is available why they were not accepted in the main tree and how to improve them further so they would.

Some of them were never submitted to the main tree. Some of them were taken from attachments to bugs here and had long been abandoned by their authors. Some were also clearly labeled by their authors as hacks, not proper fixes. And some were submitted to staging because the author doesn't want them in the main tree. IMO, including patches that are never intended to go into the main tree is contrary to the stated goal of wine-staging, but I'm not running things.

If the patch review process would work conveniently for contributors there would be no need for Wine staging to begin with.

One change that came out of the last WineConf is that patches are now submitted to wine-devel, where discussion takes place, rather than to wine-patches.

[froschmaterial]

Some of them were never submitted to the main tree. Some of them were taken from attachments to bugs here and had long been abandoned by their authors. Some were also clearly labeled by their authors as hacks, not proper fixes. And some were submitted to staging because the author doesn't want them in the main tree.

Unfortunately there is no documentation to trace which of these cases applies to a specific patch set.

There seem to be barriers to contribution even if you submit a working patch to a bug. If patches get abandoned by their authors that is a polite description that they took the challenge to fix the bug but were not prepared to take the "contribution challenge", or they simply gave up after their submissions were rejected or got frustrated by the submission process. I can't see how submitting to a different mailing list solves the issue of uncommited patches.

E.g you fix a bug and do it the right way but then are asked to write a test case. Fair enough. You don't know how to make that happen, so you give up, after all YOUR problem is fixed However, there is also no other person who could take up that tiny extra work as there is no procedural documentation about the status of the fix. So a valid fix sits around and rusts and everyone wonders why.

With github you would have a pending pull request, others comment on it, review and approve it, automated tests are run, and in this case attach a "test missing" label to the pending fix. If someone in charge ultimately rejects the pull request one would at least add a short note why. In terms of mentoring, there seems one willing to help a contributor and walk him through the arcane arts of patch submissions.

If you look at the patch rejection rate, even for core developers, there seem to be two distinct challenges: a) solving the issue at hand b) getting your patches accepted, ideally by slicing them into tiny patches to be submitted one by one and a lot of patience and stoic indifference to rejections. Think Supermario, try and fail, try and fail, try and succeed. That is fun. If the stakes are too high and you fail too many times, you simply give up playing the video game or trying to contribute your code.

[dimesio]

I can't see how submitting to a different mailing list solves the issue of uncommited patches.

With separate mailing lists, there were people who subscribed to wine-patches and submitted patches, but since they weren't subscribed to wine-devel, if there was feedback, they would never see it. Having one list doesn't solve all problems, but it does solve that one.

[ObsequiousNewt]

I'm not sure why you think using github or some tool would help.

Wine has a review process, it looks like this: https://source.winehq.org/patches/
Staging had a very similar review process in 2017: https://dev.wine-staging.com/patches/

The problem was very clearly that the Staging folks lacked the time or motivation to actually send things upstream. Not that I can necessarily blame them.

[giaco79]

I'm not sure why you think using github or some tool would help.

Wine has a review process, it looks like this: https://source.winehq.org/patches/
Staging had a very similar review process in 2017: https://dev.wine-staging.com/patches/

The problem was very clearly that the Staging folks lacked the time or motivation to actually send things upstream. Not that I can necessarily blame them.

I'm giving an external point of view, I've never tried to submit a Wine patch, but unless I'm missing something the Wine patches page looks very basic.
You can see the the test bot results, the status, and the reviewer name, but the discussion happens in the mailing list. It's not easy to follow, it's not interactive.

Taking github pull requests as an example, the reviewer can add general comments to the pull request, and even add inline comments about a specific line of code.
It wouldn't solve all the problems, but maybe a more interactive review process would make the whole process a lot smoother?

[ObsequiousNewt]

I'm not sure why you think using github or some tool would help.

Wine has a review process, it looks like this: https://source.winehq.org/patches/
Staging had a very similar review process in 2017: https://dev.wine-staging.com/patches/

The problem was very clearly that the Staging folks lacked the time or motivation to actually send things upstream. Not that I can necessarily blame them.

I'm giving an external point of view, I've never tried to submit a Wine patch, but unless I'm missing something the Wine patches page looks very basic.
You can see the the test bot results, the status, and the reviewer name, but the discussion happens in the mailing list. It's not easy to follow, it's not interactive.

Taking github pull requests as an example, the reviewer can add general comments to the pull request, and even add inline comments about a specific line of code.
It wouldn't solve all the problems, but maybe a more interactive review process would make the whole process a lot smoother?

You can click on the triangle next to a patch name, and see all replies to that patch.

[froschmaterial]

Let me give you one recent example from the patch watcher:

A fairly unknown contributor Zhiyi Zhang committed patches to fix memory leaks. These patches were rejected because it was not deemed necessary to fix them. Of course such patches are low hanging fruits. If I were him or her I would never commit a patch to wine again.

The "rejected" stage is as arrogant as it may get:

The patch has been rejected with a comment on wine-devel or #winehackers.
The patch contains an obvious error that you are expected to figure out yourself.

It was case one, here is the reason provided on wine-devel:

"There's no reason to fix leaks in short-lived apps like the build tools, it's only making the code more complex for no benefit."

When there are memory leaks in your code you obviously did an embarrassing mistake. If someone attempts to fix it, you reject the fix and tell that the mistake was intentional.

To which the submitter had to answer in a typical phrasing to keep face.

Yeah, it has little benefit. But I was thinking doing so would make others not reporting the same bugs again.

When you get contributers to apologize for sending trivial bug fixes, something is rotten. And the rottenness also extends to higher level submissions such as unmerged fixes from staging.

[ObsequiousNewt]

I won't argue that the attitude on the wine-devel patch list is less than friendly and helpful, although I think you may be giving people too little credit (on both sides). That said, if there is a personal problem, I fail to see how using a different set of tools for organization would help.

[froschmaterial]

You are right. I don't think anyone on the devel list is malicious and you have excellent coders there with lots of experiences. Tools alone don't help. And in a way as coders we do not care if people are nice to us in what they say, when we write shitty code and they tell us exactly that and explain, that keeps us hooked and attached. It is like in the arts, a good music teacher notices your shortcomings and helps you to improve and perfect your art of playing music. You don't improve with a teacher who just compliments you.

Many people get into programming because they like it how the compiler puts small challenges on them, spots their mistakes and makes them revisit their code. The purpose of tools is to make the process smooth and to catch errors. The introduction of automated tests and test driven development already improved the development process a lot. The art is not to be polite to others but to get others motivated to contribute more or to improve their contributions. For wine contributers there could be many automated checks and review stages before you even contribute it: do you support the right c syntax dialect? Do the spaces follow the coding style? Are patches "too big"? The "too big" issue may be quite significant when a project focuses on avoiding regressions. Most wine regular contributor perfected their contributing in a way that they sent quite small patches that just resolve a single aspect and do not mess with others code. For wine there seems to be a specific way to develop your code in a sane way. Wine patches are always highly readable and well understandable and focussed n what they do. Now, the way wine core developers work and how other developers work when they fix bugs or write code is different. They have to learn how to slice their code into patches that fit the coding practice of the project and one could not really blame the wine developers for that source of frustration.

I stumbled upon a mail to the devel list on the future of staging that made me think.
https://www.winehq.org/pipermail/wine-d ... 23095.html
The point is here not what he says but how he communicates in coded language, that says a lot.