Saving wine version in preferences with HTML
Saving wine version in preferences with HTML
I noticed in the preferences that one can change the Wine version they wish to display they are using. My wine version was different than all the ones listed in the drop down menu so I went into my HTML inspector and changed the value of currently selected wine version, "2.0.4" (without quotes) to the one I have, "2.20 (Staging)" (without quotes). Miraculously, my change was saved and is now an extra selection in the drop down list of wine versions as well as being the default value. I'm new to this site so I don't know the importance of that setting, but is it supposed to be that easy to modify?
Re: Saving wine version in preferences with HTML
No, it's not; it's a bug that needs to be fixed, similar to https://bugs.winehq.org/show_bug.cgi?id=22798.yetoo wrote:I'm new to this site so I don't know the importance of that setting, but is it supposed to be that easy to modify?
Please don't use plugins to modify any of the dropdown lists. If you do that and submit a test report with an invalid value, the test report will never be visible to others.
Re: Saving wine version in preferences with HTML
Dimesio,dimesio wrote:No, it's not; it's a bug that needs to be fixed, similar to https://bugs.winehq.org/show_bug.cgi?id=22798.yetoo wrote:I'm new to this site so I don't know the importance of that setting, but is it supposed to be that easy to modify?
Please don't use plugins to modify any of the dropdown lists. If you do that and submit a test report with an invalid value, the test report will never be visible to others.
I still think the version selection is too restrictive. I'm now getting a lot of reports saying: "Also, I am running wine 2.0.3 not .4 as listed", etc.
I don't see any reason not to have all of the set of versions 2.x and 3.x available.
The real issue was that previously users could trawl back to versions that were ridiculously old - in a huge drop-down list.
Now we seem to have swung in the opposite (draconian) direction!
What am I supposed to do? Tell people their test results are invalid - because we don't list their "very slightly old" tested version?
I am not clear what achieves??!
Bob
Re: Saving wine version in preferences with HTML
Because that would create a dropdown list of 30+ items, most of them too old to be of interest.I don't see any reason not to have all of the set of versions 2.x and 3.x available.
The AppDB is set to show the 8 most recent releases; that's an increase from what it used to be (https://bugs.winehq.org/show_bug.cgi?id=42779). With the normal release schedule, version numbers stay on the list for about 3 1/2 months. For Wine, that's a long time--if anyone filed a bug or asked for help here on the forum for a three month old version of Wine, the first thing they would be told would be to upgrade and retest.
Re: Saving wine version in preferences with HTML
Okay fair enough...dimesio wrote:Because that would create a dropdown list of 30+ items, most of them too old to be of interest.I don't see any reason not to have all of the set of versions 2.x and 3.x available.
The AppDB is set to show the 8 most recent releases; that's an increase from what it used to be (https://bugs.winehq.org/show_bug.cgi?id=42779). With the normal release schedule, version numbers stay on the list for about 3 1/2 months. For Wine, that's a long time--if anyone filed a bug or asked for help here on the forum for a three month old version of Wine, the first thing they would be told would be to upgrade and retest.
But please can I negotiate for the 2 Wine Stable (2.0.x branch) releases and at least the most recent Wine Staging release - to be locked in.
I know Linux distribution maintainers - they're a bit slow about releasing updates... Even the Ubuntu packages that WineHQ deliver haven't been updated past 3.0-rc6 - although 3.1 has been out for a few days.
Major architectural changes - like wine-vulkan have yet to be integrated - so there isn't much reason for a delay in this case...
I'm seeing a lot of Wine Staging 2.0.4 / 3.0 tests getting submitted for example... I can't really argue with these versions - because the users have no other choice of what to put... But then what actual meaning does the version field have - for a test submission?
Bob
Re: Saving wine version in preferences with HTML
What if the drop down was searchable. What if the dropdown wasn't a dropdown, but a box?dimesio wrote:Because that would create a dropdown list of 30+ items, most of them too old to be of interest.I don't see any reason not to have all of the set of versions 2.x and 3.x available.
The AppDB is set to show the 8 most recent releases; that's an increase from what it used to be (https://bugs.winehq.org/show_bug.cgi?id=42779). With the normal release schedule, version numbers stay on the list for about 3 1/2 months. For Wine, that's a long time--if anyone filed a bug or asked for help here on the forum for a three month old version of Wine, the first thing they would be told would be to upgrade and retest.
Re: Saving wine version in preferences with HTML
No. We tried locking in stable releases for several years, and it was a maintenance mess. I also see no reason why stable and staging users should get special treatment--everyone gets the same amount of time to submit test reports.Bob Wya wrote: But please can I negotiate for the 2 Wine Stable (2.0.x branch) releases and at least the most recent Wine Staging release - to be locked in.
Not true; there are WineHQ 3.0 packages, but they are labeled stable rather than development. 3.0 is still on the AppDB dropdown list, and will be for another three months. If there are no new WineHQ packages by the time 3.0 drops off the list that will indeed be a problem, but it will be a packaging problem, not an AppDB one, just like the current issue with wine-staging.Even the Ubuntu packages that WineHQ deliver haven't been updated past 3.0-rc6 - although 3.1 has been out for a few days.
They should be rejected. Those users can always test the latest development or stable release, and if there are problems that they know are solved in wine-staging, mention that in the Extra comments section.I'm seeing a lot of Wine Staging 2.0.4 / 3.0 tests getting submitted for example...
That would give us a searchable list of versions we don't want test reports for.yetoo wrote:What if the drop down was searchable. What if the dropdown wasn't a dropdown, but a box?
Re: Saving wine version in preferences with HTML
What is the current issue with Staging?dimesio wrote: just like the current issue with wine-staging.
And another question that comes to mind: Games that work with Staging 2.21, but don't work in Wine 3.0 or 3.1. Do you need new test reports for them? Or do you track internally that those bugs have been reported before, and fixes only landed in Staging? And should we just wait till when/if next Staging comes out?
Re: Saving wine version in preferences with HTML
https://bugs.winehq.org/show_bug.cgi?id=44406Dox wrote:What is the current issue with Staging?
Sure. You can submit test reports for each new Wine version, even if nothing has changed. You can even submit multiple test reports for the same Wine version, so long as they are from different systems (different OS and/or hardware).And another question that comes to mind: Games that work with Staging 2.21, but don't work in Wine 3.0 or 3.1. Do you need new test reports for them?
Don't confuse the AppDB with Bugzilla. Bugs are reported in Bugzilla, and yes, they are tracked there, so don't submit duplicate bugs. But that has nothing to do with the AppDB.Or do you track internally that those bugs have been reported before, and fixes only landed in Staging?
It's entirely up to you whether you want to test/use the development branch while waiting for another Staging release. If you're affected by a specific bug marked STAGED, you might want to follow it to see when/if the fix is added to the main branch.And should we just wait till when/if next Staging comes out?