Re: [Bug 14810] WinHttp needs to be implemented
On Sun, Aug 10, 2008 at 6:43 PM, <wine-bugs(a)winehq.org> wrote:
http://bugs.winehq.org/show_bug.cgi?id=14810
--- Comment #4 from Erich Hoover <ehoover(a)mines.edu> 2008-08-10 18:43:16 --- This whole DLL has a total of 27 functions, 14 of which are currently exposed, and only 1 is "implemented". I put some work into implementing enough of the DLL to get RA3 to authenticate and found that it needs 9 of the functions to operate properly. I think it is reasonable to say that implementing the rest of the functions for WinHttp would not be too difficult. I do not think that this particular issue is anywhere close to a broad-spectrum "Win32 API needs to be implemented".
Of course it's not the same scale as all of the Win32 API. It was an analogy illustrating why the bug is superfluous. On the other hand, you're vastly underestimating the amount of work needed to properly implement winhttp. You might want to chat with Zac Brown who is working on implementing winhttp right now. Also, please don't post in closed bugs. -- James Hawkins
I am trying to argue that the bug does not warrant closure, wine-devel does not seem like an appropriate venue for such a discussion. I am quite familiar with how much effort goes into properly implementing a full-fledged library for working with HTTP, I have done it several times in several languages. I initiated that bug to serve as a starting point to say "we need a minimal implementation", which I think was successfully illustrated. I was not aware that someone was already working on something, otherwise I would have contacted them in order to get a head start. Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes. Wine is not my full time job, and I think it is unreasonable to expect people to keep track of this kind of off-the-tree activity without some sort of database like bugzilla to keep track of who is doing what. As I'm sure other people do, I only have time to do work on Wine when I'm on my vacation. Erich Hoover ehoover(a)mines.edu On Sun, Aug 10, 2008 at 5:52 PM, James Hawkins <truiken(a)gmail.com> wrote:
On Sun, Aug 10, 2008 at 6:43 PM, <wine-bugs(a)winehq.org> wrote:
http://bugs.winehq.org/show_bug.cgi?id=14810
--- Comment #4 from Erich Hoover <ehoover(a)mines.edu> 2008-08-10 18:43:16 --- This whole DLL has a total of 27 functions, 14 of which are currently exposed, and only 1 is "implemented". I put some work into implementing enough of the DLL to get RA3 to authenticate and found that it needs 9 of the functions to operate properly. I think it is reasonable to say that implementing the rest of the functions for WinHttp would not be too difficult. I do not think that this particular issue is anywhere close to a broad-spectrum "Win32 API needs to be implemented".
Of course it's not the same scale as all of the Win32 API. It was an analogy illustrating why the bug is superfluous. On the other hand, you're vastly underestimating the amount of work needed to properly implement winhttp. You might want to chat with Zac Brown who is working on implementing winhttp right now. Also, please don't post in closed bugs.
-- James Hawkins
I am trying to argue that the bug does not warrant closure, wine-devel does not seem like an appropriate venue for such a discussion.
It depends on the bug. The consensus seems to be that this bug is invalid, and I'm inclined to agree. A better bug would be something about Command and Conquer Red Alert 3 Beta and how it fails. The bug, as you opened it, doesn't have enough details about the specific failure you're trying to fix.
Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes.
If not stepping on someone's toes is your wish, is it too much to ask that you ask on wine-devel? You don't have to read it on a regular basis to post a question, and it's rather well known that Zac's been working on WinHttp. We could have pointed you in the right direction. --Juan
On Sun, Aug 10, 2008 at 6:39 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
I am trying to argue that the bug does not warrant closure, wine-devel does not seem like an appropriate venue for such a discussion.
It depends on the bug. The consensus seems to be that this bug is invalid, and I'm inclined to agree. A better bug would be something about Command and Conquer Red Alert 3 Beta and how it fails. The bug, as you opened it, doesn't have enough details about the specific failure you're trying to fix.
At the time I opened the bug that would not have done any good, the only thing I could have said at that time is that it failed on WinHttpOpen. After minimally implementing things I could now have added a more complete list if the bug were still open.
Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes.
If not stepping on someone's toes is your wish, is it too much to ask that you ask on wine-devel? You don't have to read it on a regular basis to post a question, and it's rather well known that Zac's been working on WinHttp. We could have pointed you in the right direction.
While this is not a particularly efficient mechanism for solving these kinds of problems, I can do that in the future. Would you mind pointing me in the direction of Zac's patches?
--Juan
At the time I opened the bug that would not have done any good, the only thing I could have said at that time is that it failed on WinHttpOpen.
That's not quite no good. Just knowing that more than one app depends on winhttp is often useful.
Would you mind pointing me in the direction of Zac's patches?
Not at all. You might try this series: http://www.winehq.org/pipermail/wine-patches/2008-July/058088.html --Juan
On Sun, Aug 10, 2008 at 7:30 PM, Erich Hoover <ehoover(a)mines.edu> wrote:
I am trying to argue that the bug does not warrant closure, wine-devel does not seem like an appropriate venue for such a discussion. I am quite familiar with how much effort goes into properly implementing a full-fledged library for working with HTTP, I have done it several times in several languages. I initiated that bug to serve as a starting point to say "we need a minimal implementation", which I think was successfully illustrated. I was not aware that someone was already working on something, otherwise I would have contacted them in order to get a head start.
Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes. Wine is not my full time job, and I think it is unreasonable to expect people to keep track of this kind of off-the-tree activity without some sort of database like bugzilla to keep track of who is doing what. As I'm sure other people do, I only have time to do work on Wine when I'm on my vacation.
Exactly. You open a bug stating that 'Command & Conquere Red Alert 3 fails to authenticate' and then add in a bug comment that the problem is because of missing required winhttp functionality. Zac then sees the bug report and adds his own comment stating whether he has time to work on it or not plus any additional information he has to help others that want to work on the bug. There's really no point in arguing about policy. We don't allow metabugs, exactly because they serve no purpose and usually hinder the development process. My original suggestion was to open a new bug report for the fact that C&C doesn't work, and that suggestion still stands. Please don't top-post on this mailing list. -- James Hawkins
On Sun, Aug 10, 2008 at 6:39 PM, James Hawkins <truiken(a)gmail.com> wrote:
Exactly. You open a bug stating that 'Command & Conquere Red Alert 3 fails to authenticate' and then add in a bug comment that the problem is because of missing required winhttp functionality. Zac then sees the bug report and adds his own comment stating whether he has time to work on it or not plus any additional information he has to help others that want to work on the bug.
I've submitted these kinds of bugs before and they have a tendency to get closed for not having enough information. Especially in this case, such a bug is nearly useless: 1) The Red Alert 3 Beta is locked to a particular license key, which it associates with a particular PC 2) I do not know what is missing until I implement things, since the entire DLL is stubs 3) There's no guarantee that the relevant person will ever see the bug report, Zac was not on the email list for this bug even though it targeted the winhttp component (there are other bugs in this component and Zac has not replied to any of them)
There's really no point in arguing about policy. We don't allow
metabugs, exactly because they serve no purpose and usually hinder the
development process.
Of the policies posted on the Wine website I have never found anything related to this discussion (http://wiki.winehq.org/Bugs comes closest, but does not discuss the issue). Even if there was such a policy posted, it is reasonable to discuss re-evaluating it when policy is incongruous with productivity. Many open source projects use metabugs, even though I would say the bug in question is not very "meta," so I'd say that there's a certain amount of burden of proof necessary before it's accurate to say that these bugs hinder the development process.
My original suggestion was to open a new bug report for the fact that C&C doesn't work, and that suggestion still stands.
I plan on it, obviously opening a bug that does not fullfil your guidelines results in it being closed rather than clarified. I find this behavior particularly irritating, I'd much prefer to be told to re-title the bug (or have it re-titled) to say something more specifically related to the application in question.
Please don't top-post on this mailing list.
Sorry, I replied to all and didn't notice the mailing list was on there (and I was not responding to a specific statement).
-- James Hawkins
Erich Hoover ehoover(a)mines.edu
On Sun, Aug 10, 2008 at 06:30:17PM -0600, Erich Hoover wrote:
Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes. Wine is not my full time job, and I think it is unreasonable to expect people to keep track of this kind of off-the-tree activity without some sort of database like bugzilla to keep track of who is doing what. As I'm sure other people do, I only have time to do work on Wine when I'm on my vacation.
I agree with others in that bugs saying such and such DLL need to be implemented are redundant. Wine development is very app-driven in that we focus on fixing particular apps instead of willy-nilly deciding to work on DLL X today. It gives priority to bugs which will help the most people (depending on the popularity of the app), and makes it easier to chart progess (M apps run well is a better metric than N DLLs are implemented). There are already some bugs in the tracker for winhttp (eg, 14381). To help out the most, please add bugs for the other apps you've mentioned that fail to run (assuming they aren't already in bugzilla, I didn't check). You could also write test cases for winhttp. This is a good way to get people started on implementing it. To see who is currently active in a particular area, you can search the mailing lists, or look at the git logs for the files, or check if there's a recent copyright on any of them. Bugs often don't get assigned to anybody. Wine is developed by a lot of otherwise unrelated people, so bugs usually just get fixed by whoever happens to be interested in them.
On Sun, Aug 10, 2008 at 7:20 PM, Dan Hipschman <dsh(a)linux.ucla.edu> wrote:
On Sun, Aug 10, 2008 at 06:30:17PM -0600, Erich Hoover wrote:
Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes. Wine is not my full time job, and I think it is unreasonable to expect people to keep track of this kind of off-the-tree activity without some sort of database like bugzilla to keep track of who is doing what. As I'm sure other people do, I only have time to do work on Wine when I'm on my vacation.
I agree with others in that bugs saying such and such DLL need to be implemented are redundant. Wine development is very app-driven in that we focus on fixing particular apps instead of willy-nilly deciding to work on DLL X today. It gives priority to bugs which will help the most people (depending on the popularity of the app), and makes it easier to chart progess (M apps run well is a better metric than N DLLs are implemented).
I agree that the title of the bug indicated as such, I was not aware that being generic like this was against some sort of unwritten policy. However, the comment specifically targeted the Red Alert 3 Beta as much as possible, since it failed immediately after WinHttpOpen.
There are already some bugs in the tracker for winhttp (eg, 14381). To help out the most, please add bugs for the other apps you've mentioned that fail to run (assuming they aren't already in bugzilla, I didn't check). You could also write test cases for winhttp. This is a good way to get people started on implementing it. To see who is currently active in a particular area, you can search the mailing lists, or look at the git logs for the files, or check if there's a recent copyright on any of them. Bugs often don't get assigned to anybody. Wine is developed by a lot of otherwise unrelated people, so bugs usually just get fixed by whoever happens to be interested in them.
The copyright on the winhttp "main.c" is in 2007 and is just stubs, otherwise i would have more actively checked the mailing lists. The other bugs in bugzilla did not appear relevant, so I made a new one. Since I'm now aware that there's someone already interested in WinHttp, I plan on doing what I can to help them get things working for RA3 so it will work by the time it comes out.
On Sun, Aug 10, 2008 at 7:20 PM, Dan Hipschman <dsh(a)linux.ucla.edu> wrote:
On Sun, Aug 10, 2008 at 06:30:17PM -0600, Erich Hoover wrote:
Honestly, I believe that this problem illustrates the need for these kind of bugs - if I had found a bug for WinHttp in bugzilla assigned to Zac then I could easily contact him. I do not have time to monitor wine-devel in order keep track of what everyone is working on so that I can keep from stepping on people's toes. Wine is not my full time job, and I think it is unreasonable to expect people to keep track of this kind of off-the-tree activity without some sort of database like bugzilla to keep track of who is doing what. As I'm sure other people do, I only have time to do work on Wine when I'm on my vacation.
I agree with others in that bugs saying such and such DLL need to be implemented are redundant. Wine development is very app-driven in that we focus on fixing particular apps instead of willy-nilly deciding to work on DLL X today. It gives priority to bugs which will help the most people (depending on the popularity of the app), and makes it easier to chart progess (M apps run well is a better metric than N DLLs are implemented).
I agree that the title of the bug indicated as such, I was not aware that being generic like this was against some sort of unwritten policy. However, the comment specifically targeted the Red Alert 3 Beta as much as possible, since it failed immediately after WinHttpOpen.
There are already some bugs in the tracker for winhttp (eg, 14381). To help out the most, please add bugs for the other apps you've mentioned that fail to run (assuming they aren't already in bugzilla, I didn't check). You could also write test cases for winhttp. This is a good way to get people started on implementing it. To see who is currently active in a particular area, you can search the mailing lists, or look at the git logs for the files, or check if there's a recent copyright on any of them. Bugs often don't get assigned to anybody. Wine is developed by a lot of otherwise unrelated people, so bugs usually just get fixed by whoever happens to be interested in them.
The copyright on the winhttp "main.c" is in 2007 and is just stubs, otherwise i would have more actively checked the mailing lists. The other bugs in bugzilla did not appear to necessarilly be relevant, so I made a new one. Since I'm now aware that there's someone already interested in WinHttp, I plan on doing what I can to help them get things working for RA3 so it will work by the time it comes out.
participants (4)
-
Dan Hipschman -
Erich Hoover -
James Hawkins -
Juan Lang