May 2007 - Wine-Devel - list.winehq.org

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > I do read through all of your bug emails, which is exactly the > problem, because I don't trust that you make the right decision on > every bug, and in some cases I've had to go back and correct it. That > is the issue. It has been a small number of cases.. > The statement still stands. Resolved isn't resolved enough for you, > but closed is...If a bug is marked resolved, I'm pretty sure it's > resolved. Obviously someone that commits patches to the upstream bugzilla tree agrees with me, because otherwise, there either wouldnt be a resolved option, OR there would be a close option on the bugs that are in any state of open, which is something I have suggested before, to cut down on list traffic. > No one has problems with people correcting bugs that are marked > incorrectly, but of the 30 or so bugs a day that you change, this case > is a small amount. If you *only* changed this class of bugs, then > that would be fine. I honestly dont see why it is such an inconvenience to you for me to close the bugs that are marked resolved. You read thru every one of my emails because you dont trust my decisions, understandable, but if you are so worried about my marking a bug wrongly, then maybe you should stop developing, and strictly focus on helping clean up bugzilla, or the inverse could be true, maybe you could just trust that if I make a status change, it is the correct thing to do, and if not, then let someone else, who does have more time on their hands, catch it. Like you said, it's a small amount of bugs that are marked incorrectly. Of that percentage, I represent an even smaller amount, and like I said, I dont blindly close bugs, I read the majority of the comments, especially the ones toward the end, and the initial report, and then make a change only when I am confident that it is the right change to make.. -- Thanks Tom

May 31, 2007

Re: Whitespace changes in an indentation patch, is it acceptable?

by Tom Spear

On 5/31/07, Dan Kegel <dank(a)kegel.com> wrote: > Now that you've fixed a couple bugs in your uninstall patch, > I think you should post the very simplest form of it possible, > without any other change mixed in. In this case, I think that > means you should do the whitespace changes in a second patch. Right, which is the way the patch is already done, I just wanted to see if making changes to the whitespace in other parts of the file (via the 2nd patch, which changes the indentation of my additions) would be considered random whitespace changes, or if it would be helpful, because it reduces filesize.. I recall a few years back (2003?) There was a discussion about removing extra whitespace at the end of lines, and someone came up with a bash/sed script to look thru the entire wine tree, strip trailing whitespace, and then somehow commit it (either with a really large diff, or by it being run on the machine that the upstream tree is on, I cant remember which). Once that was done, the tarballs shrank by at least 1-2 megs in download size, and even more uncompressed. IMHO it may be time to do that again... -- Thanks Tom

May 31, 2007

Re: Bug triage, or spam?

by James Hawkins

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > > Marking bugs as closed has nothing to do with bug triage. Triaging > > bugs would be a really helpful thing, but mass-closing bugs does > > nothing but give subscribers a whole lot of emails to delete. We > > don't keep track of stats like other projects, so there's really no > > point to blindly close all bugs that are resolved, instead of closing > > bugs on a case by case basis. > > I'm not blindly closing all bugs marked resolved.. It seems to me > that you didnt real thru all of the emails, but I have been posting > comments, etc before closing, and there are some that are marked > resolved that I did not close, or that I even reopened based on the > most recent commentS that indicate the bug might not be fixed, or > might actully be a real wine bug.. > I do read through all of your bug emails, which is exactly the problem, because I don't trust that you make the right decision on every bug, and in some cases I've had to go back and correct it. That is the issue. > > > since invalid isnt really "resolved", and neither is works for me > > > > But closing these bugs somehow makes them "resolved" for you? > > It's an organizational thing, if they are closed, then we know for > sure that they are resolved. The statement still stands. Resolved isn't resolved enough for you, but closed is...If a bug is marked resolved, I'm pretty sure it's resolved. > Since everyone is prone to marking a bug > as invalid when it is really a bug, or works for me when it really > should be open because some users are experiencing it but not others, > leaving it as resolved just says that the person who resolved it was > too lazy to close it, and that they didn't check back to make sure > that some other users didnt have the same problem.. Case in point: > bug 3889, has been resolved as worksforme (i did it over a year ago), > when it is really a bug, and has never truely been resolved in wine. > I just looked back thru the conversation that took place on wine-devel > and saw no definitive response saying that the bug was fixed by an > alexandre patch, and saw nothing that says the bug is not a bug, so I > am about to reopen it and ask if the issue is fixed in current wine. > No one has problems with people correcting bugs that are marked incorrectly, but of the 30 or so bugs a day that you change, this case is a small amount. If you *only* changed this class of bugs, then that would be fine. -- James Hawkins

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > Marking bugs as closed has nothing to do with bug triage. Triaging > bugs would be a really helpful thing, but mass-closing bugs does > nothing but give subscribers a whole lot of emails to delete. We > don't keep track of stats like other projects, so there's really no > point to blindly close all bugs that are resolved, instead of closing > bugs on a case by case basis. I'm not blindly closing all bugs marked resolved.. It seems to me that you didnt real thru all of the emails, but I have been posting comments, etc before closing, and there are some that are marked resolved that I did not close, or that I even reopened based on the most recent commentS that indicate the bug might not be fixed, or might actully be a real wine bug.. > > since invalid isnt really "resolved", and neither is works for me > > But closing these bugs somehow makes them "resolved" for you? It's an organizational thing, if they are closed, then we know for sure that they are resolved. Since everyone is prone to marking a bug as invalid when it is really a bug, or works for me when it really should be open because some users are experiencing it but not others, leaving it as resolved just says that the person who resolved it was too lazy to close it, and that they didn't check back to make sure that some other users didnt have the same problem.. Case in point: bug 3889, has been resolved as worksforme (i did it over a year ago), when it is really a bug, and has never truely been resolved in wine. I just looked back thru the conversation that took place on wine-devel and saw no definitive response saying that the bug was fixed by an alexandre patch, and saw nothing that says the bug is not a bug, so I am about to reopen it and ask if the issue is fixed in current wine. -- Thanks Tom

May 31, 2007

Re: GDI+: headers and one test

by Chris Robinson

On Thursday 31 May 2007 06:59:09 am Francois Gouget wrote: > --- /dev/null > +++ b/include/GdiplusTypes.h > [...] > +typedef enum { > [...] > +} Status; > > Hmm, this is not the same as the PSDK. The PSDK only defines 'enum > Status { ... }' which, in theory, should only allow one to use 'enum > Status' and not 'Status'. Yet the PSDK headers seem to make use of > 'Status'. This might be different in C++ though... > So on the whole it's probably ok to use a typedef. I just prefer to > bring this up so others can chime in. C++ auto-typedefs structs/classes, enums, and the like. enum Status { }; in C++ would be equivilant to: typedef enum Status { } Status; in C. And yes, both the enum and typedef can have the same name.. the compiler is smart enough to tell the difference between 'enum Status' and 'Status' being used as types. Both can be used interchangeabley, too.

May 31, 2007

re: Whitespace changes in an indentation patch, is it acceptable?

by Dan Kegel

Tom wrote: >Hi all, just curious, in my work on uninstaller, I am writing my >patches to where when indentation is changed, due to adding a for >loop, it is done in a separate patch file. I was wondering if it is >acceptable to make whitespace changes to other parts of the file in >that same patch. In general, mixing large whitespace changes with small functional changes make it hard to code review the functional change. But either way can be fine, it just depends on the situation. Now that you've fixed a couple bugs in your uninstall patch, I think you should post the very simplest form of it possible, without any other change mixed in. In this case, I think that means you should do the whitespace changes in a second patch. - Dan

May 31, 2007

Re: Bug triage, or spam?

by James Hawkins

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > Hi all, I just have a quick question.. > > I got a message from someone last night asking me to stop closing bugs > because I'm spamming the list, however I also received a message from > someone a couple of nights ago thanking me for doing bug triage.. > Which is it, and if it is both, then what draws the line between > triage and spam, and how do I close stale bugs without it being > considered spam? > Marking bugs as closed has nothing to do with bug triage. Triaging bugs would be a really helpful thing, but mass-closing bugs does nothing but give subscribers a whole lot of emails to delete. We don't keep track of stats like other projects, so there's really no point to blindly close all bugs that are resolved, instead of closing bugs on a case by case basis. > since invalid isnt really "resolved", and neither is works for me But closing these bugs somehow makes them "resolved" for you? -- James Hawkins

May 31, 2007

Re: Bug triage, or spam?

by Marcus Meissner

On Thu, May 31, 2007 at 10:04:00AM -0500, Tom Spear wrote: > On 5/31/07, Ben Hodgetts <ben(a)atomnet.co.uk> wrote: > >Can someone explain to me the point of closing bugs please? If it's > >resolved one way or another then surely that's enough? Just seems like a > >waste of effort to be honest. > > Well, I can tell you this about it, it's supposed to work like this: > > - User reports bug > - Developer looks into bug, and eventually fixes it, at which point he > marks it resolved, and asks user to verify > - User says yes it is resolved and marks it verified, or says no it is > not, at which point developer reopens bug, and the process repeats > - Once marked verified, developer then goes back and closes bug. > > It hardly ever works that way, unfortunately, but I prefer to see a > bunch of closed bugs than ones that are sitting marked resolved as > invalid, or resolved as works for me, etc, since invalid isnt really > "resolved", and neither is works for me.. Thats why I go thru and > close the bugs that are just left resolved for more than a month or 2. Well, but in theory they could sit at resolved until the end of time ;) But keep it up, people can just delete those RESOLVED->CLOSED transition mails. Ciao, Marcus

May 31, 2007

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Jacek Caban

Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > > >> Yes, that's my plan, but I'm not sure why it's important for this patch. >> Currently Wine downloads always the same Gecko version that was never >> updated, so this check should work with current Wine. It will change >> once we will switch to the new version. I have patches that will use >> query encoded in URL to specify the package version and it will use the >> same defined version string as version check in this patch, so switching >> to the new Gecko won't be much more than one line patch.. It requires >> changes both in Wine and redirecting php script. I have patches for both >> and this was the first patch in this direction. I only have to test the >> rest of patches and send them (hopefully I will find the time to do it >> tonight). >> > > My concern is that this sort of thing needs to be planned correctly to > work in the long run, and it's not clear what the purpose of that > version check is. Is there a dependency that would make Wine require a > specific version? What happens if you use a new Gecko with an old > Wine? Can you make different versions coexist? > The plan is to pass the version in URL query. Then the redirecting script will take care on choosing the correct file from SourceForge. It's backward compatible as older Wine won't pass the version so script will assume that an old Gecko is requested. The new Gecko doesn't work with old Wine (that's why we have to guaranty that it will download an old Gecko). It's because we depend on some Gecko behaviors that have changed. It's both due to Wine (we have to do some not nice tricks, to not say ugly hacks, to make loading document work correctly) and not perfect backward compatibility of Gecko. Also it's not guarantied that newer Wine will work with older Gecko. Currently it will work, that's why I think simple message is enough for now to not force people to download over 5MB if their apps work without it. But we have to use some unfrozen interfaces and they may change in the future preventing backward compatibility. Although we probably could add some workarounds when it will happen, I would be painful to support few Gecko version. So if it will happen in the future, then we can change this check to never use older Gecko (and perhaps add a nice updater). By coexisting different versions you mean in one Wine prefix? Yes, it would be possible, but I don't see much point of it. If you think it should be done this way, I may implement so (it prevents current patches, these changes would be in another peace of code). >> We are very far from being able to support other archs, so I thought >> it's not worth to care about it ATM. >> > > But then there's no sense in adding #ifdefs for it. Putting the > architecture in the request wouldn't be much harder, and would avoid > hardcoding in the client knowledge about what files are available on > the server. > I've sent patches that replace previous ones. There are removed #ifdefs. We may back to arch problem later, just like we do now with different versions. Thanks, Jacek

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, Ben Hodgetts <ben(a)atomnet.co.uk> wrote: > Can someone explain to me the point of closing bugs please? If it's > resolved one way or another then surely that's enough? Just seems like a > waste of effort to be honest. Well, I can tell you this about it, it's supposed to work like this: - User reports bug - Developer looks into bug, and eventually fixes it, at which point he marks it resolved, and asks user to verify - User says yes it is resolved and marks it verified, or says no it is not, at which point developer reopens bug, and the process repeats - Once marked verified, developer then goes back and closes bug. It hardly ever works that way, unfortunately, but I prefer to see a bunch of closed bugs than ones that are sitting marked resolved as invalid, or resolved as works for me, etc, since invalid isnt really "resolved", and neither is works for me.. Thats why I go thru and close the bugs that are just left resolved for more than a month or 2. -- Thanks Tom

May 31, 2007