Wineconf follow up: Wine Usage Data Collection
Hello All, Just wanted to continue the thread from Wineconf about tracking usage data in Wine. We had discussed adding an opt-in system at first run where all invokations of Wine would send a token to WineHQ to track the number of times users run given applications to help direct development. Thoughts? --Zach
On Sun, Oct 5, 2008 at 11:22 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
Hello All,
Just wanted to continue the thread from Wineconf about tracking usage data in Wine. We had discussed adding an opt-in system at first run where all invokations of Wine would send a token to WineHQ to track the number of times users run given applications to help direct development. Thoughts?
--Zach
I like this idea. Couple unaddressed problems: If it's stored in WINEPREFIX, then each time a new prefix is used, they'll get the prompt each time. Then again, maybe most people aren't doing this. How are we tracking apps? By filename/md5sum/filesize/installed filepath? -Austin
On Mon, Oct 6, 2008 at 12:32 AM, Austin English <austinenglish(a)gmail.com> wrote:
If it's stored in WINEPREFIX, then each time a new prefix is used, they'll get the prompt each time. Then again, maybe most people aren't doing this. How are we tracking apps? By filename/md5sum/filesize/installed filepath?
I don't think enough people really use prefixes currently for it to matter though I'd like to see that change in the future as part of the desktop integration work we discussed at WineConf. Also I think a mixture of name/sha1 hash is a good way to go. It would do wonders for us to tie in to appdb in case there is are tricks and tips for various versions of software such as stock, sp1, sp2, etc. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Steven Edwards wrote:
On Mon, Oct 6, 2008 at 12:32 AM, Austin English <austinenglish(a)gmail.com> wrote:
If it's stored in WINEPREFIX, then each time a new prefix is used, they'll get the prompt each time. Then again, maybe most people aren't doing this. How are we tracking apps? By filename/md5sum/filesize/installed filepath?
I don't think enough people really use prefixes currently for it to matter though I'd like to see that change in the future as part of the desktop integration work we discussed at WineConf. Also I think a mixture of name/sha1 hash is a good way to go. It would do wonders for us to tie in to appdb in case there is are tricks and tips for various versions of software such as stock, sp1, sp2, etc.
How about this for an idea: The first time and every time thereafter they create a .wine directory, they will get the opt-in question? Any other WINEPREFIX will be ignored. James McKenzie
On Tue, Oct 7, 2008 at 10:19 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
Steven Edwards wrote:
On Mon, Oct 6, 2008 at 12:32 AM, Austin English <austinenglish(a)gmail.com> wrote:
If it's stored in WINEPREFIX, then each time a new prefix is used, they'll get the prompt each time. Then again, maybe most people aren't doing this. How are we tracking apps? By filename/md5sum/filesize/installed filepath?
I don't think enough people really use prefixes currently for it to matter though I'd like to see that change in the future as part of the desktop integration work we discussed at WineConf. Also I think a mixture of name/sha1 hash is a good way to go. It would do wonders for us to tie in to appdb in case there is are tricks and tips for various versions of software such as stock, sp1, sp2, etc.
How about this for an idea:
The first time and every time thereafter they create a .wine directory, they will get the opt-in question?
Any other WINEPREFIX will be ignored.
James McKenzie
I don't see why we need to ignore other prefixes. My concern was simply do we run this for every prefix creation and store it within the prefix, or are we going to store it elsewhere, under for example: '~/.local/wine/survey-status'. Either way, I'd love to see this done, I'm moreso just curious about implementation. - Austin
I don't see why we need to ignore other prefixes. My concern was simply do we run this for every prefix creation and store it within the prefix, or are we going to store it elsewhere, under for example: '~/.local/wine/survey-status'.
Either way, I'd love to see this done, I'm moreso just curious about implementation.
- Austin
I agree.. and im curious: are there any other information bits we would like to collect or display at firstrun / wineprefixcreate? If people see other needs for it I think it might be appropriate for Wine to have a 'first run' dialog with some basic information / tips and the question about survey opt-in.
On Wed, Oct 8, 2008 at 1:50 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
I agree.. and im curious: are there any other information bits we would like to collect or display at firstrun / wineprefixcreate? If people see other needs for it I think it might be appropriate for Wine to have a 'first run' dialog with some basic information / tips and the question about survey opt-in.
You guys need to realize that in any given day we, as developers, destroy and recreate wineprefixes several times. Having a popup for every wineprefix creation will be extremely annoying. If this can't be done behind the scenes, say as a winecfg option, then I wouldn't expect to get much support for this. -- James Hawkins
On Wed, Oct 8, 2008 at 2:59 PM, James Hawkins <truiken(a)gmail.com> wrote:
You guys need to realize that in any given day we, as developers, destroy and recreate wineprefixes several times. Having a popup for every wineprefix creation will be extremely annoying. If this can't be done behind the scenes, say as a winecfg option, then I wouldn't expect to get much support for this.
-- James Hawkins
I don't see why it would present any technical problem to have a way to disable this.. wineprefixcreate --quiet?
On Wed, Oct 8, 2008 at 2:02 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
On Wed, Oct 8, 2008 at 2:59 PM, James Hawkins <truiken(a)gmail.com> wrote:
You guys need to realize that in any given day we, as developers, destroy and recreate wineprefixes several times. Having a popup for every wineprefix creation will be extremely annoying. If this can't be done behind the scenes, say as a winecfg option, then I wouldn't expect to get much support for this.
-- James Hawkins
I don't see why it would present any technical problem to have a way to disable this.. wineprefixcreate --quiet?
Because then the policy is opt-out instead of opt-in. Also, wineprefixcreate is run automatically now anytime a wineprefix is created; how will you handle the quiet option for those cases? I don't have a problem with someone figuring out a way to get usage statistics and implementing it as long as it doesn't change our work flow. -- James Hawkins
On Wed, Oct 8, 2008 at 3:06 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 2:02 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
On Wed, Oct 8, 2008 at 2:59 PM, James Hawkins <truiken(a)gmail.com> wrote:
You guys need to realize that in any given day we, as developers, destroy and recreate wineprefixes several times. Having a popup for every wineprefix creation will be extremely annoying. If this can't be done behind the scenes, say as a winecfg option, then I wouldn't expect to get much support for this.
-- James Hawkins
I don't see why it would present any technical problem to have a way to disable this.. wineprefixcreate --quiet?
Because then the policy is opt-out instead of opt-in. Also, wineprefixcreate is run automatically now anytime a wineprefix is created; how will you handle the quiet option for those cases? I don't have a problem with someone figuring out a way to get usage statistics and implementing it as long as it doesn't change our work flow.
-- James Hawkins
so make it default not show, but allow distros to reverse that.
On Wed, Oct 8, 2008 at 2:12 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
so make it default not show, but allow distros to reverse that.
That doesn't solve the problem. We want usage statistics; therefore, in this hypothetical situation we want the distros to enable it. We're back to the original problem of bugging developers and users who don't want a popup. -- James Hawkins
On Wed, Oct 8, 2008 at 2:06 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 2:02 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
On Wed, Oct 8, 2008 at 2:59 PM, James Hawkins <truiken(a)gmail.com> wrote:
You guys need to realize that in any given day we, as developers, destroy and recreate wineprefixes several times. Having a popup for every wineprefix creation will be extremely annoying. If this can't be done behind the scenes, say as a winecfg option, then I wouldn't expect to get much support for this.
-- James Hawkins
I don't see why it would present any technical problem to have a way to disable this.. wineprefixcreate --quiet?
Because then the policy is opt-out instead of opt-in. Also, wineprefixcreate is run automatically now anytime a wineprefix is created; how will you handle the quiet option for those cases? I don't have a problem with someone figuring out a way to get usage statistics and implementing it as long as it doesn't change our work flow.
-- James Hawkins
How about we add it in the Winecfg about box, below the registration information, to enable the survey? Most people won't be bothered, but those curious people that search in there would find it. Send a note along to wine-users/add it in the announcements, so people can be aware of it. - Austin
On Wed, Oct 8, 2008 at 3:14 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 2:06 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 2:02 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
On Wed, Oct 8, 2008 at 2:59 PM, James Hawkins <truiken(a)gmail.com> wrote:
You guys need to realize that in any given day we, as developers, destroy and recreate wineprefixes several times. Having a popup for every wineprefix creation will be extremely annoying. If this can't be done behind the scenes, say as a winecfg option, then I wouldn't expect to get much support for this.
-- James Hawkins
I don't see why it would present any technical problem to have a way to disable this.. wineprefixcreate --quiet?
Because then the policy is opt-out instead of opt-in. Also, wineprefixcreate is run automatically now anytime a wineprefix is created; how will you handle the quiet option for those cases? I don't have a problem with someone figuring out a way to get usage statistics and implementing it as long as it doesn't change our work flow.
-- James Hawkins
How about we add it in the Winecfg about box, below the registration information, to enable the survey?
Most people won't be bothered, but those curious people that search in there would find it. Send a note along to wine-users/add it in the announcements, so people can be aware of it.
- Austin
i dont think wede get enough responses in that scenario.
On Wed, Oct 8, 2008 at 1:50 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
I don't see why we need to ignore other prefixes. My concern was simply do we run this for every prefix creation and store it within the prefix, or are we going to store it elsewhere, under for example: '~/.local/wine/survey-status'.
Either way, I'd love to see this done, I'm moreso just curious about implementation.
- Austin
I agree.. and im curious: are there any other information bits we would like to collect or display at firstrun / wineprefixcreate? If people see other needs for it I think it might be appropriate for Wine to have a 'first run' dialog with some basic information / tips and the question about survey opt-in.
Off hand: distribution name/version kernel version lspci graphics driver gcc version
On Wed, Oct 8, 2008 at 3:04 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 1:50 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
I don't see why we need to ignore other prefixes. My concern was simply do we run this for every prefix creation and store it within the prefix, or are we going to store it elsewhere, under for example: '~/.local/wine/survey-status'.
Either way, I'd love to see this done, I'm moreso just curious about implementation.
- Austin
I agree.. and im curious: are there any other information bits we would like to collect or display at firstrun / wineprefixcreate? If people see other needs for it I think it might be appropriate for Wine to have a 'first run' dialog with some basic information / tips and the question about survey opt-in.
Off hand: distribution name/version kernel version lspci graphics driver gcc version
I mean thats good information to have for the survey... (also the key -- the apps a user runs) but what would we want to tell users? How to use wine, how to configure it etc.
Off hand: distribution name/version kernel version lspci graphics driver gcc version
Those strike me as a pretty large set, and perhaps more than people want to divulge. If they're having problems, with, say, graphics drivers or kernels, hopefully bugzilla will tell us that. I think we're more curious about the apps people are running. Do we really need everything else? --Juan
On Wed, Oct 8, 2008 at 2:07 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
Off hand: distribution name/version kernel version lspci graphics driver gcc version
Those strike me as a pretty large set, and perhaps more than people want to divulge. If they're having problems, with, say, graphics drivers or kernels, hopefully bugzilla will tell us that. I think we're more curious about the apps people are running. Do we really need everything else? --Juan
I'm not saying we NEED all that, just things that MIGHT be useful. App names/sha1sum should be the priority.
Juan Lang wrote:
Off hand: distribution name/version kernel version lspci graphics driver gcc version
Those strike me as a pretty large set, and perhaps more than people want to divulge. If they're having problems, with, say, graphics drivers or kernels, hopefully bugzilla will tell us that. I think we're more curious about the apps people are running. Do we really need everything else? --Juan
I think we do Juan.. reason being is that information is not always captured when people put things into bugzilla.. if we had a way that its entered initially (if we could gather it automagically) then have them attach the file when they do a bugzilla that might work a little better... this of course is just my opinion... chris
I think we do Juan.. reason being is that information is not always captured when people put things into bugzilla.. if we had a way that its entered initially (if we could gather it automagically) then have them attach the file when they do a bugzilla that might work a little better...
I disagree that this should be a goal. Our intention was to sample the applications that people are running, and not to require it. That is, it should be an opt-in survey. Getting better bugzilla reports should be orthogonal to this, and would be a task better handled as a crash tracker like Dr. Watson. And to preempt comments like, "Why not do both?", we shouldn't provider better support to people that opt-in to our optional survey than to those who don't. --Juan
Juan Lang wrote:
I think we do Juan.. reason being is that information is not always captured when people put things into bugzilla.. if we had a way that its entered initially (if we could gather it automagically) then have them attach the file when they do a bugzilla that might work a little better...
I disagree that this should be a goal. Our intention was to sample the applications that people are running, and not to require it. That is, it should be an opt-in survey. Getting better bugzilla reports should be orthogonal to this, and would be a task better handled as a crash tracker like Dr. Watson.
And to preempt comments like, "Why not do both?", we shouldn't provider better support to people that opt-in to our optional survey than to those who don't. --Juan so why not collect it period when wine starts up... dump it to a file and let people know we are doing it. Have the ability to turn it off.. once the file gets to a certain size send it in if there is an active internet connection or zip and mail it off...
chris
On Wed, Oct 8, 2008 at 2:34 PM, Chris Ahrendt <celticht32(a)aol.com> wrote:
Juan Lang wrote:
I think we do Juan.. reason being is that information is not always captured when people put things into bugzilla.. if we had a way that its entered initially (if we could gather it automagically) then have them attach the file when they do a bugzilla that might work a little better...
I disagree that this should be a goal. Our intention was to sample the applications that people are running, and not to require it. That is, it should be an opt-in survey. Getting better bugzilla reports should be orthogonal to this, and would be a task better handled as a crash tracker like Dr. Watson.
And to preempt comments like, "Why not do both?", we shouldn't provider better support to people that opt-in to our optional survey than to those who don't. --Juan
so why not collect it period when wine starts up... dump it to a file and let people know we are doing it. Have the ability to turn it off.. once the file gets to a certain size send it in if there is an active internet connection or zip and mail it off...
chris
If someone only uses Wine periodically/infrequently, we're unlikely to see it. Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. 2) We don't want to bug developers with this, because we'll frequently go through dozens of wineboots in a day. Current proposals: 1) Run a dialog box on first wineboot asking to opt in. 2) Disable the dialog box by default, but allow distros to enable it, so we don't bother devs. 3) Run the dialog box periodically, reminding users about the survey. 4) Put an option in Winecfg to allow opting in, similar to Ubuntu's installer's advanced options allowing to opt-in to the package survey. Problems for propsals: 1) Will annoy developers, which means, won't happen. 2) Possibly viable, but we're then depending on the distros to enable it. While Ubuntu/Suse probably won't be a problem (nudges Scott/Marcus), the others may be. 3) More trouble to implement, and annoying. 4) Depends on users finding the survey and opting in. Will give slightly biased info, as well as less than options 1 or 2 would. I'm leaning toward 2 or 4. The others are annoying/not worth it. Remember, we're not going to get EVERYONE. The idea, however, is to at least get SOMETHING, so we know where/what to target. Currently, we're shooting in the dark. -Austin
On Wed, Oct 8, 2008 at 3:20 PM, Austin English <austinenglish(a)gmail.com> wrote:
If someone only uses Wine periodically/infrequently, we're unlikely to see it.
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. 2) We don't want to bug developers with this, because we'll frequently go through dozens of wineboots in a day.
Current proposals: 1) Run a dialog box on first wineboot asking to opt in. 2) Disable the dialog box by default, but allow distros to enable it, so we don't bother devs. 3) Run the dialog box periodically, reminding users about the survey. 4) Put an option in Winecfg to allow opting in, similar to Ubuntu's installer's advanced options allowing to opt-in to the package survey.
Problems for propsals: 1) Will annoy developers, which means, won't happen. 2) Possibly viable, but we're then depending on the distros to enable it. While Ubuntu/Suse probably won't be a problem (nudges Scott/Marcus), the others may be. 3) More trouble to implement, and annoying. 4) Depends on users finding the survey and opting in. Will give slightly biased info, as well as less than options 1 or 2 would.
I'm leaning toward 2 or 4. The others are annoying/not worth it. Remember, we're not going to get EVERYONE. The idea, however, is to at least get SOMETHING, so we know where/what to target. Currently, we're shooting in the dark.
You're not thinking about the end result of 2. In a peachy world, all distros would enable what we ask them to, then we still get bugged by popups. 4 is the only viable opt-in option. -- James Hawkins
On Wed, Oct 8, 2008 at 3:28 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 3:20 PM, Austin English <austinenglish(a)gmail.com> wrote:
If someone only uses Wine periodically/infrequently, we're unlikely to see it.
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. 2) We don't want to bug developers with this, because we'll frequently go through dozens of wineboots in a day.
Current proposals: 1) Run a dialog box on first wineboot asking to opt in. 2) Disable the dialog box by default, but allow distros to enable it, so we don't bother devs. 3) Run the dialog box periodically, reminding users about the survey. 4) Put an option in Winecfg to allow opting in, similar to Ubuntu's installer's advanced options allowing to opt-in to the package survey.
Problems for propsals: 1) Will annoy developers, which means, won't happen. 2) Possibly viable, but we're then depending on the distros to enable it. While Ubuntu/Suse probably won't be a problem (nudges Scott/Marcus), the others may be. 3) More trouble to implement, and annoying. 4) Depends on users finding the survey and opting in. Will give slightly biased info, as well as less than options 1 or 2 would.
I'm leaning toward 2 or 4. The others are annoying/not worth it. Remember, we're not going to get EVERYONE. The idea, however, is to at least get SOMETHING, so we know where/what to target. Currently, we're shooting in the dark.
You're not thinking about the end result of 2. In a peachy world, all distros would enable what we ask them to, then we still get bugged by popups. 4 is the only viable opt-in option.
-- James Hawkins
If developers are building from git and not enabling that option, we wouldn't be bugged by it, only end users would.
On Wed, Oct 8, 2008 at 3:31 PM, Austin English <austinenglish(a)gmail.com> wrote:
If developers are building from git and not enabling that option, we wouldn't be bugged by it, only end users would.
Ok, then you need to clarify what your plan with this 'option' is. Is this an option passed to configure that is disabled by default? If the configure option is enabled, then the user gets a popup? -- James Hawkins
On Wed, Oct 8, 2008 at 3:34 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 3:31 PM, Austin English <austinenglish(a)gmail.com> wrote:
If developers are building from git and not enabling that option, we wouldn't be bugged by it, only end users would.
Ok, then you need to clarify what your plan with this 'option' is. Is this an option passed to configure that is disabled by default? If the configure option is enabled, then the user gets a popup?
-- James Hawkins
To list as well: I didn't propose that option, I proposed 4. I simply summarized the proposals to clarify things. Looking at Zach's proposal: "so make it default not show, but allow distros to reverse that." I'd say build the survey in to run on first wineboot, when the directory doesn't exist. Give an option in configure that would enable the survey, but otherwise have it off by default. Or maybe in tools/wine.inf, but does wineboot parse that before or after creating the directory? -Austin
On Wed, Oct 8, 2008 at 4:42 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 3:34 PM, James Hawkins <truiken(a)gmail.com> wrote:>>
Ok, then you need to clarify what your plan with this 'option' is. Is this an option passed to configure that is disabled by default? If the configure option is enabled, then the user gets a popup?
-- James Hawkins
To list as well:
I didn't propose that option, I proposed 4. I simply summarized the proposals to clarify things. Looking at Zach's proposal: "so make it default not show, but allow distros to reverse that."
I'd say build the survey in to run on first wineboot, when the directory doesn't exist. Give an option in configure that would enable the survey, but otherwise have it off by default. Or maybe in tools/wine.inf, but does wineboot parse that before or after creating the directory?
-Austin
Sorry for being so trite, was typing with tablet during class.. Yes, I think that there should be a configure option which is "Enable first run popup". Thus the default state is no pop up. Thus we could ask distros, when building their binaries, to enable this option. And since its not on by default it wouldn't bug any devs building from IGT> And yes I do think this data would be valuable. Especially for the d3d people who have a very rough idea of what to focus on (from what they've told us at wineconf).
2008/10/9 Zachary Goldberg <zgold(a)bluesata.com>:
And yes I do think this data would be valuable. Especially for the d3d people who have a very rough idea of what to focus on (from what they've told us at wineconf).
That's not quite what Stefan said, actually. The issue is that while there are obviously some games that are very popular like World of Warcraft, Call of Duty, Counter-Strike, etc., there simply isn't a single application that almost everyone runs. Another issue is that compared to regular applications, games have a relatively short lifespan. If a game remains popular for an entire year that's a relatively long time already. So it's not so much that we don't know what to focus on, but rather that it makes more sense to work on things like "fix surface management" or "implement dualhead" than on "make Red Alert 3 work perfectly", although those aren't mutually exclusive, of course. You also have to consider that debugging a problem often takes just as much or more time as implementing a fix, which is a bit of a waste if you already know there are parts of the code that have problems which will probably cause a bug in some application.
Dan, noticed something missing with winetricks... when you install Vj# libraries.. it requires installer 3 and there is only installer 2 in the list... chris
On Wed, Oct 8, 2008 at 13:20, Austin English <austinenglish(a)gmail.com> wrote:
If someone only uses Wine periodically/infrequently, we're unlikely to see it.
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts.
Will the number of times a Windows program is run give you the information you're looking for, though? I know that, as a user, the programs I run the most are the ones that work the best, and so don't need much effort. On the other hand, the programs that I run the least are the ones that don't work, which seem to me to be the ones that need effort. -- Mark Wagner
On Wed, Oct 8, 2008 at 3:38 PM, Mark Wagner <carnildo(a)gmail.com> wrote:
On Wed, Oct 8, 2008 at 13:20, Austin English <austinenglish(a)gmail.com> wrote:
If someone only uses Wine periodically/infrequently, we're unlikely to see it.
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts.
Will the number of times a Windows program is run give you the information you're looking for, though? I know that, as a user, the programs I run the most are the ones that work the best, and so don't need much effort. On the other hand, the programs that I run the least are the ones that don't work, which seem to me to be the ones that need effort.
-- Mark Wagner
Presumably, each app would only be submitted once per user. How this would be done has yet to be explored. -Austin
2008/10/8 Austin English <austinenglish(a)gmail.com>:
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. Just curious, but do any actual developers really care about this? My feeling is that bugzilla gives a pretty good idea of what people are having trouble with already. (Not necessarily trying to shoot it down, but keep in mind that receiving and processing the data will require some infrastructure as well, and I wonder if it's worth all the trouble.)
"Henri Verbeet" <hverbeet(a)gmail.com> writes:
2008/10/8 Austin English <austinenglish(a)gmail.com>:
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. Just curious, but do any actual developers really care about this? My feeling is that bugzilla gives a pretty good idea of what people are having trouble with already. (Not necessarily trying to shoot it down, but keep in mind that receiving and processing the data will require some infrastructure as well, and I wonder if it's worth all the trouble.)
I'm very skeptical too. I certainly don't think it's worth all the complexity that has been discussed around here, and in any case it can't be allowed to slow down the normal app startup code path. If there's really a need for this, it should be done somewhat like the Debian tracker, say by having a package that installs a cron job that looks for exe files and sends a list of the ones that have been accessed recently, or something along those lines. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
"Henri Verbeet" <hverbeet(a)gmail.com> writes:
2008/10/8 Austin English <austinenglish(a)gmail.com>:
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. Just curious, but do any actual developers really care about this? My feeling is that bugzilla gives a pretty good idea of what people are having trouble with already. (Not necessarily trying to shoot it down, but keep in mind that receiving and processing the data will require some infrastructure as well, and I wonder if it's worth all the trouble.)
I'm very skeptical too. I certainly don't think it's worth all the complexity that has been discussed around here, and in any case it can't be allowed to slow down the normal app startup code path.
If there's really a need for this, it should be done somewhat like the Debian tracker, say by having a package that installs a cron job that looks for exe files and sends a list of the ones that have been accessed recently, or something along those lines.
Problem with that Alexandre is that alot of people get freaked out when you start talking about doing that sort of thing. Several companies have tried it and people had alot of problems with it. So this gets down to the base question what are we trying to accomplish with this functionality that we are not getting now with the current process? What can we change in the current process that would enhance that to fill the short comings? Does anything need to be changed? Personally, for what its worth, I think our time would be better spent improving some form of error detection so that users would have an easier time identifying where the issues might be. Automated dump process and upload would be my thought. Then when the dump is recieved it can be parsed with something along the lines of patchwatcher to determine the component that failed. If we want we could even have the user opt in at that point to send the dump in or just trash it. Thoughts? Chris
On Thu, Oct 9, 2008 at 9:32 AM, Chris Ahrendt <celticht32(a)aol.com> wrote:
Alexandre Julliard wrote:
"Henri Verbeet" <hverbeet(a)gmail.com> writes:
2008/10/8 Austin English <austinenglish(a)gmail.com>:
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. Just curious, but do any actual developers really care about this? My feeling is that bugzilla gives a pretty good idea of what people are having trouble with already. (Not necessarily trying to shoot it down, but keep in mind that receiving and processing the data will require some infrastructure as well, and I wonder if it's worth all the trouble.)
I'm very skeptical too. I certainly don't think it's worth all the complexity that has been discussed around here, and in any case it can't be allowed to slow down the normal app startup code path.
If there's really a need for this, it should be done somewhat like the Debian tracker, say by having a package that installs a cron job that looks for exe files and sends a list of the ones that have been accessed recently, or something along those lines.
Problem with that Alexandre is that alot of people get freaked out when you start talking about doing that sort of thing. Several companies have tried it and people had alot of problems with it.
So this gets down to the base question what are we trying to accomplish with this functionality that we are not getting now with the current process? What can we change in the current process that would enhance that to fill the short comings? Does anything need to be changed?
Personally, for what its worth, I think our time would be better spent improving some form of error detection so that users would have an easier time identifying where the issues might be. Automated dump process and upload would be my thought. Then when the dump is recieved it can be parsed with something along the lines of patchwatcher to determine the component that failed. If we want we could even have the user opt in at that point to send the dump in or just trash it.
Thoughts?
We have a hard enough time determining which component is causing the bug as it is. It would be near impossible to automate that detection. -- James Hawkins
James Hawkins wrote:
On Thu, Oct 9, 2008 at 9:32 AM, Chris Ahrendt <celticht32(a)aol.com> wrote:
Alexandre Julliard wrote:
"Henri Verbeet" <hverbeet(a)gmail.com> writes:
2008/10/8 Austin English <austinenglish(a)gmail.com>:
Currently, we've got two problems: 1) We want to collect Wine usage data, so we know where to concentrate our efforts. Just curious, but do any actual developers really care about this? My feeling is that bugzilla gives a pretty good idea of what people are having trouble with already. (Not necessarily trying to shoot it down, but keep in mind that receiving and processing the data will require some infrastructure as well, and I wonder if it's worth all the trouble.) I'm very skeptical too. I certainly don't think it's worth all the complexity that has been discussed around here, and in any case it can't be allowed to slow down the normal app startup code path.
If there's really a need for this, it should be done somewhat like the Debian tracker, say by having a package that installs a cron job that looks for exe files and sends a list of the ones that have been accessed recently, or something along those lines.
Problem with that Alexandre is that alot of people get freaked out when you start talking about doing that sort of thing. Several companies have tried it and people had alot of problems with it.
So this gets down to the base question what are we trying to accomplish with this functionality that we are not getting now with the current process? What can we change in the current process that would enhance that to fill the short comings? Does anything need to be changed?
Personally, for what its worth, I think our time would be better spent improving some form of error detection so that users would have an easier time identifying where the issues might be. Automated dump process and upload would be my thought. Then when the dump is recieved it can be parsed with something along the lines of patchwatcher to determine the component that failed. If we want we could even have the user opt in at that point to send the dump in or just trash it.
Thoughts?
We have a hard enough time determining which component is causing the bug as it is. It would be near impossible to automate that detection.
I am sure there are some things that may be automated somewhat... or we can compare exceptions etc... that way we can get some idea of atleast what the hot bugs are at the time... Maybe one of the first tasks towards this is to improve problem determination... or debugging.. Chris
On Thu, Oct 9, 2008 at 2:09 PM, Chris Ahrendt <celticht32(a)aol.com> wrote:
I am sure there are some things that may be automated somewhat... or we can compare exceptions etc... that way we can get some idea of atleast what the hot bugs are at the time... Maybe one of the first tasks towards this is to improve problem determination... or debugging..
How do you propose to 'improve problem determination or debugging'? -- James Hawkins
James Hawkins wrote:
On Thu, Oct 9, 2008 at 2:09 PM, Chris Ahrendt <celticht32(a)aol.com> wrote:
I am sure there are some things that may be automated somewhat... or we can compare exceptions etc... that way we can get some idea of atleast what the hot bugs are at the time... Maybe one of the first tasks towards this is to improve problem determination... or debugging..
How do you propose to 'improve problem determination or debugging'?
-- James Hawkins well you asked lol : My wish list would be:
1) Some form of a Standard Gui Debugger GDB integration / eclipse etc.. 2) A way to select the debug flags used with an explanation of what each is for... +seh is for this +relay does that...etc.... 3) When you do +relay you could open separate output for each thread or send the +relay output for each thread to a different pipe so we can then pipe that information to a file or open that pipe and use a tool to look at whats going on. 4) The ability to turn each of the +relay wine thread output on or off... Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. A best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesn't give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window or output with a list of the important wine structures or resources that can be watched as the application runs with some explination of what those structures are for. And do the same with the dump. If the execution space is in an application output that fact. If we are in wine and we have the symbols of where we are then dump the code where we are too =) 6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) and yes I know Gdb sort of works.. why not make it so it really works.. its not like I am asking to use VC++ to debug wine here lol. 7) Loading of application from gui debugger and then run it. This can be done with gdb now but its not the easiest in the world to do. This would be nice if it was made easier. 8) Ability to look at a stack and backtrace in the GUI or exception list and have the symbol associated with the backtrace placed in the execution trace. 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking.... Unreachable Code Checking (I think is being done to an extent with Dan's runs of valgrind) 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes.... 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... (also update the GIT page with the latest instructions. Some of us are not GIT people by background... CVS, etc.. so there is a really steep learning curve and its easy to mess a local GIT tree up and have to reload. 15) Link to whats fixed in the new GIT tree... or a list of it... something off the main WINEHQ page that says ok here is 1.1.15 here is what we fixed... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... You have to remember alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. And no I am not criticizing wine in the least by the above. I really enjoy using wine and hacking around learning things. I want it to be the best it can be.. Chris
On Thursday 09 October 2008 22:06:55 Chris Ahrendt wrote: Whew, long post. I'll tackle this as I go.
My wish list would be:
1) Some form of a Standard Gui Debugger GDB integration / eclipse etc..
gdb has a standard GUI? Which would that be in your case? I hear Eclipse is useable for C development, but does any Wine dev use it?
2) A way to select the debug flags used with an explanation of what each is for... +seh is for this +relay does that...etc....
See http://wiki.winehq.org/DebugChannels and http://bugs.winehq.org/show_bug.cgi?id=638 Feel free to flesh out the wiki page.
3) When you do +relay you could open separate output for each thread or send the +relay output for each thread to a different pipe so we can then pipe that information to a file or open that pipe and use a tool to look at whats going on.
So you need to start guessing which thread to capture? Do you know about +tid and tools/examine-relay ?
4) The ability to turn each of the +relay wine thread output on or off... Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. A best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesn't give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere.
Actually most of the errors that disappeared for me when using +relay were races and stack smashing bugs. Those are always a pain to debug, and will probably disappear as well when only using parts of +relay.
5) A window or output with a list of the important wine structures or resources that can be watched as the application runs with some explination of what those structures are for. And do the same with the dump. If the execution space is in an application output that fact. If we are in wine and we have the symbols of where we are then dump the code where we are too =)
I don't know how this would be implemented, but it sounds like a performance drag to me. So I take you intend this to be a debugging tool. What's wrong with using a debugger?
6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) and yes I know Gdb sort of works.. why not make it so it really works.. its not like I am asking to use VC++ to debug wine here lol.
Most debugger GUIs on Linux are (somewhat sucky) frontends to gdb. I'm pretty sure it's possible to create something similar for winedbg.
7) Loading of application from gui debugger and then run it. This can be done with gdb now but its not the easiest in the world to do. This would be nice if it was made easier.
Sure, I'm pretty sure this can be done in aforementioned GUI.
8) Ability to look at a stack and backtrace in the GUI or exception list and have the symbol associated with the backtrace placed in the execution trace.
Yup, see above.
9) Value Watches within the GUI.
And again. This all sounds like stuff you'd expect from a debugger. I take you volunteer to write a GUI for winedbg?
10) Code Checking Some sort of bounds checking... Uninitialized variable checking.... Unreachable Code Checking (I think is being done to an extent with Dan's runs of valgrind)
We're already running static analysis tools and other checkers on the code.
11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now.
What GUI? The last time you talked about a GUI you were talking about a frontend for winedbg. I don't see how this links to coding standards. If you're talking about IDEs, I think you will find that a lot of the Wine developers consider vim or emacs to be all the GUI they need.
12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes....
From the editor?
13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc...
Your losing me here with "the GUI". Is this going to be a debuger-codechecker-coffe-machine-mail-reader-vcs-compiler program that will also fetch my newspaper?
14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... (also update the GIT page with the latest instructions. Some of us are not GIT people by background... CVS, etc.. so there is a really steep learning curve and its easy to mess a local GIT tree up and have to reload.
If you can point out what's missing from http://wiki.winehq.org/GitWine I'll gladly add more information to that page.
15) Link to whats fixed in the new GIT tree... or a list of it... something off the main WINEHQ page that says ok here is 1.1.15 here is what we fixed...
It's called "changelog", and we already have that.
16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad...
I'm pretty sure that once patchwatcher is stable, it'll get a prominent link.
17) Generation of the GIT patch and then mail it to the list through a button...
Oh, from the swiss army knife GUI?
You have to remember alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. And no I am not criticizing wine in the least by the above. I really enjoy using wine and hacking around learning things. I want it to be the best it can be..
From looking at what you proposed, you're looking at a couple of man-years of work on a GUI few if any of the existing Wine devs will use. And without wanting to sound elitist, working on Wine is hard. At least hard enough to make learning some command-line tools we require easy.
I'm convinced that someone who can't learn enough on the command-line to run the basic git, configure and make steps will have a very hard time trying to develop Wine code. That being said, I think a GUI for winedbg would be a nice tool, and if we can come up with a tool that makes translations easier, that'd be helpful as well. I just don't think that it's possible to create The One GUI To Rule Them All. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
Kai Blin wrote:
On Thursday 09 October 2008 22:06:55 Chris Ahrendt wrote:
Whew, long post. I'll tackle this as I go.
Yes I am sorry for the long post =) but he did ask for some of my thoughts =)
My wish list would be:
1) Some form of a Standard Gui Debugger GDB integration / eclipse etc..
gdb has a standard GUI? Which would that be in your case? I hear Eclipse is useable for C development, but does any Wine dev use it?
I think it is a standard GUI... sorry meant something like DDD or KDB not gdb.. my bad =) Hell there is an eclipse plugin interface for gdb as well as the internal debug framework of eclipse.
2) A way to select the debug flags used with an explanation of what each is for... +seh is for this +relay does that...etc....
See http://wiki.winehq.org/DebugChannels and http://bugs.winehq.org/show_bug.cgi?id=638
Feel free to flesh out the wiki page.
Ok I will take a look and see what I can add... but this is a little more than just the wiki... I don't always have internet connectivity when I am hacking around in wine (I travel alot so am on an airplane for upto 20+ hours at a time with no connectivity) so it would be nice to have something simple that set up the command shell for wine say with a checkbox and context based help before starting the wine session. If its not in a gui but a stand alone tool that would be fine as well.
3) When you do +relay you could open separate output for each thread or send the +relay output for each thread to a different pipe so we can then pipe that information to a file or open that pipe and use a tool to look at whats going on.
So you need to start guessing which thread to capture? Do you know about +tid and tools/examine-relay ?
No.... I would like to be able to either pipe each thread to a different window or file.... in the case of looking through a relay log I have in the past had to manually sort through the log to determine that thread A is having the problem because of XY or Z.... it just would be nice not to have to do this. OR if its a thread we know is having the problem then be able to say I just want the +relay on that thread...IE we know only X processes run on thread A and we are having a problem with that process and not the others.. then why clutter the logs with the extra stuff... it just makes debugging alot easier. ESP when debugging some of the more esoteric and weird bugs.
4) The ability to turn each of the +relay wine thread output on or off... Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. A best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesn't give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere.
Actually most of the errors that disappeared for me when using +relay were races and stack smashing bugs. Those are always a pain to debug, and will probably disappear as well when only using parts of +relay.
Maybe maybe not... +relay could and has for me masked the problem with races or such because the timing is off.... so we can say the problem exists both ways.. however I think it would help with timing related bugs and determining whats going on rather than not... less stuff going out = less overhead.
5) A window or output with a list of the important wine structures or resources that can be watched as the application runs with some explination of what those structures are for. And do the same with the dump. If the execution space is in an application output that fact. If we are in wine and we have the symbols of where we are then dump the code where we are too =)
I don't know how this would be implemented, but it sounds like a performance drag to me. So I take you intend this to be a debugging tool. What's wrong with using a debugger?
Nothing is wrong with using a debugger.... its an enhancement to one... when working on the kernel for another OS (not Win or Linux) we had the ability within the debugger to have a common list of kernel or PM level structures we could select to watch and the tool would show them.. Just think it would be a nice to have for Wine as well.
6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) and yes I know Gdb sort of works.. why not make it so it really works.. its not like I am asking to use VC++ to debug wine here lol.
Most debugger GUIs on Linux are (somewhat sucky) frontends to gdb. I'm pretty sure it's possible to create something similar for winedbg.
Cool thats all I am saying here... is provide the hooks =) the gdb interface for winedbg is really kludgy.... or I found it to be... so just get rid of the middleman =)
7) Loading of application from gui debugger and then run it. This can be done with gdb now but its not the easiest in the world to do. This would be nice if it was made easier.
Sure, I'm pretty sure this can be done in aforementioned GUI.
yep....
8) Ability to look at a stack and backtrace in the GUI or exception list and have the symbol associated with the backtrace placed in the execution trace.
Yup, see above.
yep...
9) Value Watches within the GUI.
And again. This all sounds like stuff you'd expect from a debugger. I take you volunteer to write a GUI for winedbg?
You provide the hooks I'll start seeing about a eclipse based plugin (its easier for me to do that than from scratch =) )
10) Code Checking Some sort of bounds checking... Uninitialized variable checking.... Unreachable Code Checking (I think is being done to an extent with Dan's runs of valgrind)
We're already running static analysis tools and other checkers on the code.
I thought so.... this was from an older list so I just included it. Would not make sense that we were not already...
11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now.
What GUI? The last time you talked about a GUI you were talking about a frontend for winedbg. I don't see how this links to coding standards. If you're talking about IDEs, I think you will find that a lot of the Wine developers consider vim or emacs to be all the GUI they need.
Any Editor is what I mean... Most editors now have the ability to specify templates (atleast the ones I have used). This is what I am talking about... sorry if I confused you on this... just if we have a certain way of doing the code.. (which we do) why not make a template for people.
12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes....
From the editor?
yes...
13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc...
Your losing me here with "the GUI". Is this going to be a debuger-codechecker-coffe-machine-mail-reader-vcs-compiler program that will also fetch my newspaper?
The debugger.... if a person has found and debugged an issue or just finds an issue.. ask for a screen dump... dump the stack to a file and so on.... maybe even collect the hardware when we dump and put that in the output as well. This is so we have a consistant set of data coming in.. We not be able to say this is a kernel bug... or this is a d3d bug but we can atleast say this is a bug only effecting X program on Y hardware.. which is a start in the direction of gathering statistics and so forth and finding where we need to focus on.
14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... (also update the GIT page with the latest instructions. Some of us are not GIT people by background... CVS, etc.. so there is a really steep learning curve and its easy to mess a local GIT tree up and have to reload.
If you can point out what's missing from http://wiki.winehq.org/GitWine I'll gladly add more information to that page.
Someone a few weeks back said the GitWINE page had not been updated in quite ahwile and needed to be. I'll see if I can remember who and where it was... it happened when I submitted a patch and Dan's patchwatcher failed because my tree had somehow got messed up and out of sync even though git claimed it was fine and upto date.
15) Link to whats fixed in the new GIT tree... or a list of it... something off the main WINEHQ page that says ok here is 1.1.15 here is what we fixed...
It's called "changelog", and we already have that.
I had a hard time finding it.... but eventually did.... so just drop this one.... other than maybe putting in a bit on the git page explaining how to list the deltas from a particular checkpoint... say all the delta's from 1.1.5 till current... that would be handy =). If GIT cant do that then no biggy....
16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad...
I'm pretty sure that once patchwatcher is stable, it'll get a prominent link.
ok cool...
17) Generation of the GIT patch and then mail it to the list through a button...
Oh, from the swiss army knife GUI?
No not the Swiss army knife gui... sheesh.... from the normal GIT GUI... have the instructions on how to do that... having something like eclipse or other frameworks spawn and do the generation is easy as its just a shell call.
You have to remember alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. And no I am not criticizing wine in the least by the above. I really enjoy using wine and hacking around learning things. I want it to be the best it can be..
From looking at what you proposed, you're looking at a couple of man-years of work on a GUI few if any of the existing Wine devs will use. And without wanting to sound elitist, working on Wine is hard. At least hard enough to make learning some command-line tools we require easy.
Not really... most of the GUI /IDE stuff is already there... its a matter of picking something and integrating what we have.. and I am not talking of doing this for the existing Dev's... this is for people coming on board... or so forth. Its not hard to have both models =). And Yes,that did come across as a little elitist but I accept the point you are trying to make... However, it is no harder than writing boot loader code for embeded devices or device drivers, or kernel code, etc... its just another bit of code... does wonderful stuff... but in the end... its just another bit of code people use. So then is there a wiki page for learning what is needed and say this is our process for developing? Just trying to help here... not everything in wine is at the level of the kernel development wise.. there are many different levels to hack on.. atleast thats my impression....
I'm convinced that someone who can't learn enough on the command-line to run the basic git, configure and make steps will have a very hard time trying to develop Wine code.
I disagree... you want M$ apps to be ported using the wine libraries... your going to get requirements like these.. There are requests for stuff like this it in a few threads and bugs where people are asking for some of this or in some of the Dist. specific mailing lists.. I am as much a command line person as the next one but like I said alot of the newer people coming to linux are not and have no desire to even begin to learn that way but want to help. And its not just a matter of learning.. its a matter of how they are used to developing and so forth. I deal with this problem every day in my RL job so I can see both sides of the issue.. But its somewhat of a loosing battle.
That being said, I think a GUI for winedbg would be a nice tool, and if we can come up with a tool that makes translations easier, that'd be helpful as well. I just don't think that it's possible to create The One GUI To Rule Them All.
Cheers, Kai
------------------------------------------------------------------------
I agree... there isnt a way to make one gui to rule them all.. but there is a need for more tooling =).. Did you see my follow on message on other thoughts as well? Has nothing to do with GUI's at all but clearing up some of the output... if not I can email it to you.. Chris
On Fri, Oct 10, 2008 at 4:00 PM, Chris Ahrendt <celticht32(a)aol.com> wrote:
Yes I am sorry for the long post =) but he did ask for some of my thoughts =)
Most debugger GUIs on Linux are (somewhat sucky) frontends to gdb. I'm pretty sure it's possible to create something similar for winedbg.
Cool thats all I am saying here... is provide the hooks =) the gdb interface for winedbg is really kludgy.... or I found it to be... so just get rid of the middleman =)
If you've found a problem with winedbg, or a certain feature is missing, then file a bug. ... ... All the rest of your wish list, and I'm pretty sure I didn't miss anything, has nothing to do with Wine in particular, or there is nothing that can be changed in Wine itself to accommodate your wishes. Most of your wishes sound like IDE integration problems that need to be brought up with those particular projects. I absolutely agree with Kai on the difficulty level. The threshold for Wine development is very high. If an interested developer can't get anything done without the items on your wish list, then how can he successfully hack on Wine? General development skills are just the door to Wine development. Once you walk through that door, fixing Wine is a whole other can of worms. -- James Hawkins
On Fri, Oct 10, 2008 at 4:14 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Fri, Oct 10, 2008 at 4:00 PM, Chris Ahrendt <celticht32(a)aol.com> wrote:
Yes I am sorry for the long post =) but he did ask for some of my thoughts =)
Most debugger GUIs on Linux are (somewhat sucky) frontends to gdb. I'm pretty sure it's possible to create something similar for winedbg.
Cool thats all I am saying here... is provide the hooks =) the gdb interface for winedbg is really kludgy.... or I found it to be... so just get rid of the middleman =)
If you've found a problem with winedbg, or a certain feature is missing, then file a bug.
... ...
All the rest of your wish list, and I'm pretty sure I didn't miss anything, has nothing to do with Wine in particular, or there is nothing that can be changed in Wine itself to accommodate your wishes. Most of your wishes sound like IDE integration problems that need to be brought up with those particular projects.
I absolutely agree with Kai on the difficulty level. The threshold for Wine development is very high. If an interested developer can't get anything done without the items on your wish list, then how can he successfully hack on Wine? General development skills are just the door to Wine development. Once you walk through that door, fixing Wine is a whole other can of worms.
-- James Hawkins
Can we get back to the original discussion and decide how we want to collect Wine usage statistics? -- -Austin
On Saturday 11 October 2008 03:11:38 Austin English wrote:
Can we get back to the original discussion and decide how we want to collect Wine usage statistics?
The only viable proposal I saw was an opt-in in winecfg. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On Sat, Oct 11, 2008 at 4:12 AM, Kai Blin <kai.blin(a)gmail.com> wrote:
On Saturday 11 October 2008 03:11:38 Austin English wrote:
Can we get back to the original discussion and decide how we want to collect Wine usage statistics?
The only viable proposal I saw was an opt-in in winecfg.
Cheers, Kai
-- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
More so than _how_ we implement it: I think, as Alexandre pointed out, that unless we can establish a clear need for this it won't get committed. I know a lot of us want this just to scratch our internal statistics monkeys (myself included) but I get the impression it doesn't pass muster unless we can say 'this will help improve Wine because of X'.
On Sat, Oct 11, 2008 at 10:19 AM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
On Sat, Oct 11, 2008 at 4:12 AM, Kai Blin <kai.blin(a)gmail.com> wrote:
On Saturday 11 October 2008 03:11:38 Austin English wrote:
Can we get back to the original discussion and decide how we want to collect Wine usage statistics?
The only viable proposal I saw was an opt-in in winecfg.
Cheers, Kai
-- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
More so than _how_ we implement it: I think, as Alexandre pointed out, that unless we can establish a clear need for this it won't get committed.
I know a lot of us want this just to scratch our internal statistics monkeys (myself included) but I get the impression it doesn't pass muster unless we can say 'this will help improve Wine because of X'.
Very true. Where it would help is with knowing what apps people are running. Many people might try Wine, and never get it to work, then give up without filing a bug. Conversely, some people might have it work perfectly fine, but since it works great, we never see bugs filed. By collecting these statistics, we'll be able to know what apps to focus on, which will give a bit better direction on which bugs to fix, which features to implement, etc. -- -Austin
On Sat, Oct 11, 2008 at 4:45 PM, Austin English <austinenglish(a)gmail.com> wrote:
Very true. Where it would help is with knowing what apps people are running. Many people might try Wine, and never get it to work, then give up without filing a bug. Conversely, some people might have it work perfectly fine, but since it works great, we never see bugs filed. By collecting these statistics, we'll be able to know what apps to focus on, which will give a bit better direction on which bugs to fix, which features to implement, etc.
That's some pretty strange logic. If most people are running app X, but we don't know about it because it runs really well so we don't get a lot of bug reports for it, then why would we want to *focus* on that app? We should be focusing on apps that don't work, or have lots of bugs. We already have this information from the thousands of bug reports in bugzilla. -- James Hawkins
On Sat, Oct 11, 2008 at 5:02 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Sat, Oct 11, 2008 at 4:45 PM, Austin English <austinenglish(a)gmail.com> wrote:
Very true. Where it would help is with knowing what apps people are running. Many people might try Wine, and never get it to work, then give up without filing a bug. Conversely, some people might have it work perfectly fine, but since it works great, we never see bugs filed. By collecting these statistics, we'll be able to know what apps to focus on, which will give a bit better direction on which bugs to fix, which features to implement, etc.
That's some pretty strange logic. If most people are running app X, but we don't know about it because it runs really well so we don't get a lot of bug reports for it, then why would we want to *focus* on that app? We should be focusing on apps that don't work, or have lots of bugs. We already have this information from the thousands of bug reports in bugzilla.
-- James Hawkins
It would give us an idea of what apps to focus on when/if moving toward graphical/app based regression testing, as well as what apps to focus on improving performance in. Though, obviously those aren't high priorities, focusing on broken apps should be. Like I said, however, some people may get fed up and not bother to file bugs. I know often times in other programs, I don't file bugs, instead, I find a way around it or switch programs. Some others, like VLC, I try to report, but never am able to since they won't confirm I'm not a robot... /end rant -- -Austin
Austin English wrote:
On Sat, Oct 11, 2008 at 5:02 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Sat, Oct 11, 2008 at 4:45 PM, Austin English <austinenglish(a)gmail.com> wrote:
Very true. Where it would help is with knowing what apps people are running. Many people might try Wine, and never get it to work, then give up without filing a bug. Conversely, some people might have it work perfectly fine, but since it works great, we never see bugs filed. By collecting these statistics, we'll be able to know what apps to focus on, which will give a bit better direction on which bugs to fix, which features to implement, etc.
That's some pretty strange logic. If most people are running app X, but we don't know about it because it runs really well so we don't get a lot of bug reports for it, then why would we want to *focus* on that app? We should be focusing on apps that don't work, or have lots of bugs. We already have this information from the thousands of bug reports in bugzilla.
-- James Hawkins
It would give us an idea of what apps to focus on when/if moving toward graphical/app based regression testing, as well as what apps to focus on improving performance in.
Though, obviously those aren't high priorities, focusing on broken apps should be. Like I said, however, some people may get fed up and not bother to file bugs. I know often times in other programs, I don't file bugs, instead, I find a way around it or switch programs. Some others, like VLC, I try to report, but never am able to since they won't confirm I'm not a robot... /end rant
In this day and age where collection of data is becoming suspect, I would seriously doubt the need to collect this data, especially on an opt-in only basis. It would prove to be worthless. The thing is that we should and could continue to fix problems as they arise and continue to advise users to provide input through Bugzilla. Speaking of Bugzilla, there is one area that needs a massive amount of work to make it more user-friendly. If I had the time.... James McKenzie
It could also be possible to have a crash count? On Sun, Oct 5, 2008 at 9:22 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote:
Hello All,
Just wanted to continue the thread from Wineconf about tracking usage data in Wine. We had discussed adding an opt-in system at first run where all invokations of Wine would send a token to WineHQ to track the number of times users run given applications to help direct development. Thoughts?
--Zach
Guillaume VanderEst wrote:
It could also be possible to have a crash count?
On Sun, Oct 5, 2008 at 9:22 PM, Zachary Goldberg <zgold(a)bluesata.com <mailto:zgold(a)bluesata.com>> wrote:
Hello All,
Just wanted to continue the thread from Wineconf about tracking usage data in Wine. We had discussed adding an opt-in system at first run where all invokations of Wine would send a token to WineHQ to track the number of times users run given applications to help direct development. Thoughts?
--Zach
------------------------------------------------------------------------
Crash Counts would definately be a required parm I should think. But then we get into what exactly is the purpose of the collection argument / discussion =) Chris
participants (12)
-
Alexandre Julliard -
Austin English -
Chris Ahrendt -
Guillaume VanderEst -
Henri Verbeet -
James Hawkins -
James McKenzie -
Juan Lang -
Kai Blin -
Mark Wagner -
Steven Edwards -
Zachary Goldberg