wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Hi there,
I want to bring this Issue up in Development Mailinglist. This proplem is about a bug that cant be fixed within wine, and The Bugtracker doesnt help it. I think this Bug is at the moment an Epic Fail of Open Source Development. (And needs to be solved so we get a accepted Fix somewhere someday) The Bug is Deadlocked.
The Problem is in this Bug roughly spoken that in some games the Mouse movement is captured and not the real position. Now X only returns the real position. This Bug is a dependance of X (If I got it right). Since this Bug appeared people worked around this Bug by improving dirty hacks (by calculating mouse movement using weird? code), and maintaining them. And when Possible to make them switchable.
Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title.
The Bug exist since 2009 - 12 - 06. And has a long thread.
I understand the move of Margolen here. For that you need to look at the Bug history (clicky: http://bugs.winehq.org/show_bug.cgi?id=6971). And I dont put blame on his move. But for this Bug wine needs another political solution. Just stopping people to write hacks, dirty or not will stop people reaching in more and more patches. This sole incident wont have an effect on hole development but most bugs I followed started with a dirty hack. And this is definitely giving the wrong impression on wine.
What I want to say, Margolens move might be technical right, but is political pretty lame. Atm I don't see any ability that the bug will be proper fixed.
1) I Xorg may implement the Problem or may not. Maybe they are even not aware(? - Haven't took a look) The Bug-tracking in wine does not contain a Link to the Bug-tracking in Xorg. 2) I am betting wine - Dev has no one working on the Bug actively.
So how can we get a proper Fix or point people towards proper fixes? Is it right to have no Dirty Hack solution which just works? Do you think by stopping Hacks you will encourage development in what (you) think is the right solution? Where is the Xorg Link for this Problem since it is a problem interesting wine but maybe not Xorg?
Before anyone asks, I don't have the Time to solve this Bug. Nor I do believe does any one of the "dirty" hackers. Or they had done it Proper by now.
Thanks Listening, hope you got the Problem I want to address.
I am not on the list since I develop nothing for wine. I would it appreciate it a lot, if I could stay with the discussion by keeping my email address in CC
Regards Peter
Peter Kovacs wrote:
Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title.
Yes, tried to, of course I can't stop anyone from hacking and posting their work, even on the same bug. All I can do is ask not to.
I did this because all of those workarounds (with exception of few) done by people, who don't understand the entire scope of the problem. They've touched (and broke) parts of DInput that have nothing to do with the problem. I've already seen several invalid bug reports that were caused by some of this hacks.
Just stopping people to write hacks, dirty or not will stop people reaching in more and more patches. This sole incident wont have an effect on hole development but most bugs I followed started with a dirty hack. And this is definitely giving the wrong impression on wine.
All of those hacks going the wrong direction. They are not solving a problem with exception of 1-2 patches which proposed solutions rejected by Alexandre.
- I Xorg may implement the Problem or may not. Maybe they are even not
aware(? - Haven't took a look) The Bug-tracking in wine does not contain a Link to the Bug-tracking in Xorg.
Yes they do, it's called XI2.
- I am betting wine - Dev has no one working on the Bug actively.
You probably right. However there were some preliminary patches for initial version(s) of Xi2. Now since it's been official part of Xorg 7.5 work can continue.
So how can we get a proper Fix or point people towards proper fixes?
Make Wine use Xi2 (I'm already working on it). Hopefully will have something available before holidays.
Is it right to have no Dirty Hack solution which just works?
Then those hacks called proper patches. But they have to work for everything. A "Dirty Hack" is something that avoids a problem for one set of apps and totally breaks things for everything else.
Vitaliy.
On Mon, Dec 7, 2009 at 15:41, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Peter Kovacs wrote:
So how can we get a proper Fix or point people towards proper fixes?
Make Wine use Xi2 (I'm already working on it). Hopefully will have something available before holidays.
Thank you very much for your work. It has been a long time coming. With the advent of XI2 we can finally see some progress!
On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Peter Kovacs wrote:
Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title.
Yes, tried to, of course I can't stop anyone from hacking and posting their work, even on the same bug. All I can do is ask not to.
Then where do you propose people put that work?
I did this because all of those workarounds (with exception of few) done by people, who don't understand the entire scope of the problem. They've touched (and broke) parts of DInput that have nothing to do with the problem. I've already seen several invalid bug reports that were caused by some of this hacks.
This has happened with other bugs/patches too, e.g., the DIB engine/the msi hack for photoshop/etc.
Is it right to have no Dirty Hack solution which just works?
Then those hacks called proper patches. But they have to work for everything. A "Dirty Hack" is something that avoids a problem for one set of apps and totally breaks things for everything else.
Considering the main ones use a environmental variable to enable the hack, the risk of that is greatly reduced.
I'm not saying these aren't hacks. By all means, they are. But users need/want a solution, so let them have it. Perhaps I'm a bit biased though, since the last game I played (Borderlands) needed this hack, so I've also been affected ;-).
Hi again,
Vitaliy this are great news. I will see if I can read a bit more about XI2. :-D Keep going. You will crack that Bug. Ill try to help if i can steal Time from somewhere. But Honestly I am no Hacker. So don't expect to much of me. I am happy if I can solve the hacks vs. patch problem :P
As I see in the reaction this is a Problem that does exist in other Bugs too. (Surprise! ;) )
I think Austin is right, stopping Hacks would slow down development. And we need people hacking.
But we also need clear, and on topic Bugzilla or winewill clutter to much. (My believe) It is at least hard for me to pick the interesting Posts in Bugzilla. Or even the Interesting Bugs. Don't know but I see a lots of App based Bug reports. They get collected it one real Bug report. Which is sometimes just the first one that got reported. Hard to search for someone not tracking Bugs. (Aside Most ppl dont look enough I bet ;) )
There are some Ideas about splitting Hacks from patches. I think this maybe an aproach to solve this. Lets see:
Looking at the Mouse "escape" Bug. We have 290 Post. Haven't count but going after my feeling at least half of the post belongs more in a Forum then in a Bug tracker. It makes technical Facts realy Hard to follow. I think Bugzilla is really not suitable for Hacker Approach. Bugzilla thinks more in terms where people actually know what they doing. And in case of wine even its best developer are shouting in the dark sometimes I bet.
If you look at the Bugzilla post, you'll find: - Tech info - Approach Ideas - Discussions - Affected Infos - Instructions for installing and Bugfixing - A lot of Hacks / patches
This is hell of different information unstructured in Bugzilla.
Thinking on it, it may be better put into a maintained Wikki with different Sections to go on. There could be a menu which links people to the basic Instructions. It can hold the Hacks. It can serve as Link Collection and Info. And most Important of all it can be overhauled. Closed Discussions can be deleted. If some real approach is found all Info can be back posted into Bugzilla by some "Officer". With that a solution is accepted and likely to enter the main tree when ready. The Idea seems to be quite flexible, but maybe it won't be structured enough. Which means more work for Maintainers (I would install community maintainers :( *sight* Maybe that Idea is not good enough, what do you think? Hmm at least in vision it would give a workflow.
Any more Ideas on this?
And what should we do with the people on the Bug. Some saying the same within the bug itself. 8 Posts today. Shall I collect them and bring them here? Maybe more Brains come up with more approaches. I hesitate to do so: To much cooks corrupt the porridge. :)
Regards Peter
On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Peter Kovacs wrote:
Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title.
Yes, tried to, of course I can't stop anyone from hacking and posting their work, even on the same bug. All I can do is ask not to.
Then where do you propose people put that work?
I did this because all of those workarounds (with exception of few) done by people, who don't understand the entire scope of the problem. They've touched (and broke) parts of DInput that have nothing to do with the problem. I've already seen several invalid bug reports that were caused by some of this hacks.
This has happened with other bugs/patches too, e.g., the DIB engine/the msi hack for photoshop/etc.
Is it right to have no Dirty Hack solution which just works?
Then those hacks called proper patches. But they have to work for everything. A "Dirty Hack" is something that avoids a problem for one set of apps and totally breaks things for everything else.
Considering the main ones use a environmental variable to enable the hack, the risk of that is greatly reduced.
I'm not saying these aren't hacks. By all means, they are. But users need/want a solution, so let them have it. Perhaps I'm a bit biased though, since the last game I played (Borderlands) needed this hack, so I've also been affected ;-).
-- -Austin
2009/12/8 Peter Kovacs legine@gmx.net:
I think Austin is right, stopping Hacks would slow down development. And we need people hacking.
Bugzilla is not the right place for hacks. There is a wine-hacks repository (naturally, completely unsupported by WineHQ). If a hack developer wants the hack to be considered seriously, wine-patches is the place to send it.
There are some Ideas about splitting Hacks from patches. I think this maybe an aproach to solve this. Lets see:
-- snip --
Thinking on it, it may be better put into a maintained Wikki with different Sections to go on.
Wiki has been suggested for AppDB before. It's not a solution there and it's certainly not an appropriate bug tracker.
A wiki replacing bugzilla would need a *lot* more man-power from the developers/maintainers to make sure the bug pages remain relevant to the bug. It would also require all the admins to have in-depth knowledge of all facets of the bugs they are maintaining. For something like this Xinput/mouse issue, that basically means someone who's working on the Xi2 driver. For the DIB engine, it's virtually impossible.
Closed Discussions can be deleted.
This does not account for regressions.
If some real approach is found all Info can be back posted into Bugzilla by some "Officer". With that a solution is accepted and likely to enter the main tree when ready. The Idea seems to be quite flexible, but maybe it won't be structured enough. Which means more work for Maintainers (I would install community maintainers :( *sight* Maybe that Idea is not good enough, what do you think?
The problem here is that community maintainers are much less likely to understand the bugs than the devleopers. For AppDB, it's ideal, as maintainers are people who run the apps and know what to expect. For Bugzilla (or any other bug tracker), only developers can be truly effective maintainers - and not just any developers, but devlopers who have or are working on related components.
Peter Kovacs wrote:
I think Austin is right, stopping Hacks would slow down development. And we need people hacking.
I'm not against hacks. I'm against dirty hacks, especially going into bugzilla!
What's a dirty hack? Something that adds commented out code, comments out original code instead of removing / changing it, have loads of white-space changes all over the place. Touches (in any way) parts that have nothing to do with the actual problem. In short - something that person didn't even bothered to look over and clean up before making it public.
If anyone still wants to maintain that sort of code - do it outside of Wine's bugzilla. There are loads of free git repositories where one can dump anything they pleased.
Also I'm having issues with people coming to bugzilla and asking how to compile Wine, and other people trying to explain how to use patch. We have forum/mailing list/IRC/wiki for this sort of stuff. Bugzilla is for bug related information and discussions on how to fix it for example, not user noise. Please keep it that way.
There are some Ideas about splitting Hacks from patches.
Easy - patches go to wine-patches. Hacks can stay in bugzilla/private GIT repos/wiki for long term stuff. Dirty hacks - should stay on PCs of their creators until cleaned.
Vitaliy.
-
Austin English -
Ben Klein -
Peter Kovacs -
Remco -
Vitaliy Margolen