RE: Please write audio tests (was: Playing ULAW sample correctly?)
>Or use a goertzel detector for the transmitted tone(s). >It is also quite simple to generate sine waves without any trig. Just another, less advanced, idea, Even easier would making a really slow square wave(~0.5 Hz) that follows a simple pattern, like 80, 80, 80, -80, -80, -80, 80, 80, 80...for 5 seconds. Then one would easily be able to find the signal in the data without any advanced tricks. Just (signal<0) or not for a specified period would suffice as detection. Maybe stutter and sound quality would not be tested, however it would be a simple first step. BTW, wouldn't stutter affect a straight line as much as it would a sound wave? If you know that the wave isn't a wave but is supposed to follow a straight line, wouldn't then all deviations be stutter? The soundsystem doesn't treat a stream of similar bytes any different from a sine wave, does it? Of course, this will obviously not work through a microphone, but I can't see how that loop would be relevant to test. Being hardware and all. //Nicklas
RE: Towards leveraging app build and unit tests as a way to test wine
> The name's not that important,though, tbh... In my experience, good names and structures are really important, since stuff like this inevitably grows. And confused newbies needs more explanations than necessary. And other people gets confused too. :-) Anyway, something like this, perhaps? winetest_app_gui - The current appinstall, tests only the finished applications through their GUI. winetest_app_build - Testing the actual building of applications. winetest_app_suite - Running applications own test suites(even if they are GUI tests) I would like to separate _build and _suite to clean up and because _build is optional. _suite could(and probably should) be also run on officially released binaries. Why not just run _app_suite tests under _app_gui? Two reasons: * Because _app_suite probably need lots of pretty advance test suite-related tools to be installed. I would like winetest_app_gui to be as clean as possible, so that it's really simple (and problem-free) to run. * I think that _app_suite (and certainly _app_build) probably only gets run by very experienced "winos" like Dan. If somebody just has an available VM somewhere(like) and like to help out, _app_gui makes this possible. _app_gui is also a little more about CPU than build environments, which should be a but easier. This is all IMHO, of course. //Nicklas
RE: newbie question
>Hello All, > >can somebody tell weather it is possible to run NT service on Wine, >especially written in Delphi VCL(TService) Regarding Delphi: TService implements the typical mechanisms of any windows service, it is actually a pretty simple wrapper, since services are pretty simple things. The fact that it is compiled under Delphi should not matter at all. So if services runs under wine, your service should as well. Unless, of course you use some unusual APIs. //Nicklas PS. Another thing for you to consider is using Free Pascal instead of Delphi(or both) and try to make the code reasonably portable so that you can run it as a native daemon under *n*x if you want to. Non-GUI applications are usually comparatively easy to port and maintain. DS.
RE: [bugzilla] donate to sponsoring bug
>It would be an administration nightmare and probably wouldn't incite the >developers >to work harder on those bugs/projects. A nightmare it would most certainly be. It is almost impossible to make these decisions without hurting peoples feelings in, probably, at least haft the cases. //Nicklas
RE: [bugzilla] donate to sponsoring bug
I suppose that this only will appear on some bugs and disregarding that people might put off fixing bugs waiting for it to become a "pay-bug". Who's going to get the money? It seems quite common that people share credit on fixing bugs, should we burden Alexandre with the task of deciding that? Wouldn't this rather be on "projects", than bugs? The bug mentioned feels more like a "project". //Nicklas -Original Message- From: wine-devel-boun...@winehq.org on behalf of sacchi antonio Sent: Wed 2009-09-16 11:47 To: wine-devel@winehq.org Subject: [bugzilla] donate to sponsoring bug hello all. I'm new here but I'd like to suggest something, what do you think about this? http://img29.imageshack.us/img29/2940/wined.png Maybe it will be good for old/hard bugs? Thanks
RE: Appinstall testing guide up on the wiki
This looks way cool. If no one else have already started, I'll have a go with PS CS4. So I looked through the CS2 script and I have two questions: 1. CS4, and many other, currently need some winetricks to install and work. Can I use winetricks or do I have to break out the downloading and installing of those components and try and do the same in the script language(using run_wait and so forth)? Basically, I guess my question is if I can add winetricks to tools? That way, we only need to fix broken .msi downloads in one place? 2. CS4 is huge, and has approximately one billion files(well maybe not). Is there some special reason all those sha1sum checks aren't in a include file? If not, what should I call the include file? photoshopcs4_inc_sha1sum or something similar? //Nicklas
RE: When do regressions become high priority for developers?
>That's a tough question. Note that Photoshop CS3 >installer has been busted for months Yep, the same problem busts the CS4 installer as well, so both CS3 and CS4 has gone from working(with tricks, practically flawless in CS4s case) to non-installable. >From what I have understood, this is not really a regression, but rather a >redesign which have caused the application to fail to install. I would not weigh Perrys problem against mine(not that I think CSx are low-profile apps), but rather say that regressions seems to be more ok when the cause is a redesign, and not when it is a common bug. I would not agree with that, though. This project is, for good reason, very cautious about accepting patches of bugs and should also be so with new functionality. Now I am not aware of the reasons for the redesign, they might be valid, but I would still think that we could learn from this in some way. If not a policy, but maybe some kind of way to tell the community of things like this happening? Yes, the development versions are development versions in the projects view, however, the community treats them as real releases. Come to think of it, the project does it as well. Bug reports regarding the release version are somewhat frowned upon. Isn't that a sign that major releases are a bit too far apart? //Nicklas PS. This is especially annoying since I've just had a positive conversation with Adobe about helping out with providing a download location for atmlib.dll so that Dan and Austin could include it into winetricks, removing the last really unsafe step of the installation. I just hope they don't watch the appdb. But then I am a developer, so I hardly notice frustration anymore. :-) DS.
RE: winequartz.drv Mac OS X UI discontinued?
>The link seems to be malformed. Can you resend it? I am really >interested in looking at this. >http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code. The trick, it seems, is to include the dot in the end. Interesting URL scheme(and snippet)... //Nicklas
RE: [Wine] Tmax Window(a propietary OS) using Wine?
> Surely the wine test suite would be a rough guide. Some more information(a marketwire article): http://www.marketwire.com/press-release/Tmax-1013937.html The company behind it: http://us.tmaxsoft.com/jsp/main.jsp //Nicklas
RE: /. wants a fork
> Not sure, but I see the second time around was a success for him. Let's not look to hard. He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest. //Nicklas
RE: Bugzilla upgrade - opening attachments in browser
> It seems the bugzilla upgrade stopped allowing opening attachments in > browser. I can comfirm this on several platforms and browsers. //Nicklas
RE: Severity levels
>> From almost the first response, the tone was quite condescending > No. Here we go. I'll try again. Yes. >If professionalism means never giving up, even when it has been >*explained* to you why your idea won't work in practice, then you >succeeded. In the end someone did explain, yes. But it took about 10 posts until anyone started to actually read what I had written and stop reading in other things into what it said. Like constantly stating that "photoshop isn't the all only application" and the like, when that had nothing to do with what my point was. I don't give up. Especially when I have time to spare. Which I did. > perhaps your idea isn't as brilliant as you think? I did not think of my idea as brilliant. In fact, I have never even remotely tried to convey that. I just thougt of it as an idea. This is exactly the kind of attitude that leads nowhere. Why even write that sentence? Did we get anywhere? > You have to treat valid critical response with the same respect as > valid positive response. I did, even if it didn't adress what I said. Although I did comment when someone persisted with strawman arguments like "should we let users in control of the project" even though I had never said anything like that. > Ever managed a project as big as Wine? In terms of number of > developers, or sheer lines of code? Have you? Regarding sheer lines of code, the main application (a portfolio/fund management system) I am working have roughly the same amount of code that wine does. Or at least around 90%. The database currently has 327 tables and customer databases range from 1-100 gigabyte in size. With regards to complexity, wine has nothing on it, at least as far as I have seen so far. So I'd say I know a thing or two about large projects. You seem to think that the wine project is some kind of huge beheamoth of a project. In fact, most fairly common business applications are just as large(especially in later years when so much code is auto-generated). One or two million LOCs is not huge. Big, but not huge. Especially, I know that when a project grows, softer values tend to become more important. And that users, handled correctly, can be more of a resource, than a liability. //Nicklas
RE: Severity levels
> +1, exactly why I muted the conversation. Not implying that I would have "won" the conversation or anything (I obviously didn't), but I did not like the way my arguments were met at all. >From almost the first response, the tone was quite condescending and no one even considered if my ideas had any actual merit at all before slamming them completely. Also, because of this, the conversation was needlessly prolonged, to the obvious annoyance of all. This also applied to perfectly valid comments i made in the AppDB. I haven't experienced such behaviour in an open source project for years. And I have, believe it or not, both participated in and, yes, managed a few. I would say that no matter how annoying I may have been to this thread, this is extremely counterproductive. In communities like this, where most people are involved for other reasons than money, it is even more important to treat others with respect. I pride myself with always trying to keep a professional attitude in my communications. Not only with customers or management, but also my peers. I would like some of the participants of this thread to consider the damage they do to the wine project when they don't. Creating technology isn't all about technology. //Nicklas PS. WOW! Reposting since a fantastic bug in outlook(loves it) totally screwed up the subject in my earlier post. DS.
Bega
> +1, exactly why I muted the conversation. Not implying that I would have "won" the conversation or anything (I obviously didn't), but I did not like the way my arguments were met at all. >From almost the first response, the tone was quite condescending and no one even considered if my ideas had any actual merit at all before slamming them completely. Also, because of this, the conversation was needlessly prolonged, to the obvious annoyance of all. This also applied to perfectly valid comments i made in the AppDB. I haven't experienced such behaviour in an open source project for years. And I have, believe it or not, both participated in and, yes, managed a few. I would say that no matter how annoying I may have been to this thread, this is extremely counterproductive. In communities like this, where most people are involved for other reasons than money, it is even more important to treat others with respect. I pride myself with always trying to keep a professional attitude in my communications. Not only with customers or management, but also my peers. I would like some of the participants of this thread to consider the damage they do to the wine project when they don't. Creating technology isn't all about technology. //Nicklas
RE: Shuttleworth on Wine
>Feel free, if you'd like. I did, that's why I knew how quick it was. >But the test suite I'm designing for my project is designed for anyone >to be able to use/run, non-interactively. Requiring sign-ups/logins is >not acceptable for it. Ok.
RE: Shuttleworth on Wine
>Is possible, but since it requires a login, the script will eventually >fail from too many login/downloads. No, i mean that one would have to register an account for oneself and manually download the files to a predetermined location. Using the same account for everyone would likely be some kind of breach of their rules anyway. I'd say, given instructions, that would take 5-10 minutes for most people. Don't you think people would consider that acceptable to make a quite important test run(i would)? //Nicklas
RE: Severity levels
>So the idiot isn't even subscribed to this group, but is spamming it anyway? >Don't feed the trolls. Hi there. I would have a hard time replying to your posts if I weren't, wouldn't you think? //Nicklas
RE: Shuttleworth on Wine
>It's the registering/download manager that makes it not useful. It's >much harder to script all of that. Why script that? One doesn't need wine to download a file, right? I really don't see what the point would be to test that. Once you downloaded the file, you don't need to download that version again. The only thing that needs testing is the actual running of that file and the following installation. Why test the Adobe website? Or have I misunderstood you completely? //Nicklas
RE: Severity levels
>make sure you're sending >mails with the same address you're receiving them on. That would be it, thanks! I feel pretty silly, I had registered to the mailing list as nicklas_at_ws.se, but my sender is my long adress, nicklas.borjesson_at_ws.se. It did not use to be that way, I forgot that it had changed. I'll change my adress and hope that solves it. Sorry if I bothered you all. //Nicklas
RE: Severity levels
>When you're not subscribed to the list, your posts have to go through >moderation. Sometimes that can take a while. I do subscribe to the list(and did, from the beginning). Or maybe subscription is more than registering to the mailing list?
RE: Shuttleworth on Wine
>Photoshop, however, is harder to test, >since it doesn't have an easy free download available. Free photoshop trial download, you do need to register (and download through the "download manager") though: https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop I have only tried to install licensed versions myself, however the installation shouldn't be totally different, except for being a bit easier to start(not having to mount a dvd and so on). I think testing the trial version would be quite sufficient. //Nicklas
RE: Shuttleworth on Wine
> a better strategy would be to target particular users who only > need one application that is almost working. At least, that's > what the model I wrote told me: > http://yokozar.org/blog/archives/48 That strategy(to no ones surprise) appeals to me, since it feels like common sense, and is close to how most of those I work/worked with think. But I am not sure it would have worked earlier in the project when having nearly working use cases would be less usual and when having broad, or no focus would make the project more interesting for its developers. Anyway, It seems likely to make the most number of users happy with the least amount of work. However, since some applications(no names) are very widespread/pirated AND close to working, it will have the effect of more or less officially focusing on certain applications, which i think would be hard to push through in this project for different reasons. To try and define the most usual "near working" use cases also means defining the most usual use cases since it then would be important to keep the "working" use cases from becoming "near working". To do that, one need needs user input which would make the project user centric. Of course, the *entire* project wouldn't have to have the same focus but it would be affected. I'd think that this would be good and appeal more to me and others as developers wanting to do good things(tm). But I know that many does not agree. //Nicklas
RE: Severity levels
>I don't believe your earlier mains have been resent. I certainly >haven't received them. Ok, then it's ok. I was afraid that there was something wrong.
RE: Shuttleworth on Wine
> The idea is to make the test as automated as possible. That way anyone > can run the tests, not just people with certain programs. Ok. Well then, either: 1. someone can mirror those two files somewhere for easier downloading, 2. or one adds one or two(quite easy) manual step to the installation instructions. 1. makes scripting possible, however, Adobe probably would not like that. However, one *could* simply ask them if it's ok. I don't see how this quite specific use case would(come on, it's a trial version) be a problem for them and I would think that getting their application working under wine would be something they would like happening. 2. I think that one should try to be a bit pragmatical. If a couple of simple manual steps is all that is needed to get an otherwise completely automated process going, it should not be allowed to be a problem. Anyway, as I said, interesting project, since we(at work) are in the progress of automating some tests that have to use a browser(testing of some ajax-y web applications). I would prefer to run these tests on a Linux system for a number of reasons. //Nicklas
RE: Shuttleworth on Wine
> http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t124024892240 > http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html Interesting project. At my workplace, we use TestComplete for testing GUI-applications, I have had some problems finding similar applications for Linux, which is kind of strange, since X11 should make it really easy to create positively fantastic testing facilities. After reading about it, though, I still don't see what would be the point in downloading the application as a part of the test, not being a part of the applications functionality. IMHO. //Nicklas
RE: Severity levels
Hi all, it seems that some of my earlier mails(and some other) has been re-mailed to the list. I don't think that our(here, at my workplace) servers has done this, rather, it feels like the mailing list server did it. So understand that I am not bombarding the list. I see that many are replying to some really old posts. //Nicklas
RE: Shuttleworth on Wine
>I think you're seriously underestimating Wine, and the amount of >'real' work it can accomplish. The world doesn't revolve around Adobe >products, contrary to what many recent converts to GNU/Linux may >think. As usual, I am not talking about myself, but people in generals' perception of it, which reflected quite well in Shuttleworths comments. Whatever you think of the guy, remember he was a developer on the Debian project in the nineties. He's not totally unitiated. And I don't think he is unique in any way. Also, (quoting http://www.winehq.org/about/): "Wine is still under development, and it is not yet suitable for general use." Doesn't say stability. Especially when the version has passed 1.0. And the *rest* of the world DO revolve around a few applications. That is why they think so. >Though, I must say, the majority of people I see/hear using Photoshop >*are* using it as a toy/hobby, not for 'real' work, i.e., a full time >job. I have the same impression. And most haven't paid for it either. Anyway, that really isn't important. The important thing is that they want it, no why.
RE: Severity levels
>No offense, but you should probably take the lack of (repeated) >responses as a sign. I did leave it alone. That post was a reaction to what I considered as bullying. The answers has almost never been to anything I have said, but rather to things I haven't said. //Nicklas PS. No, I am new to the wine project. But there is a world outside of it. DS.
RE: Severity levels
>However, a developer should be aware of the impact on the user experience and >the user's determined severity of a problem. That has been my point all the time. I was told that the users perceptions were not important since, a least according what I understood, they could not be trusted to be objective in their classification. Also, it was not very important to know their priorities anyway. >Users should not be determining this through the use of the severity and >priority fields. I have discussed the use of an impact field to have the >user state what impact the problem has on their ability to use/install a >particular application. However, I thought adding a extra field would be too bold a proposition, so I proposed to change the severity field instead(which I felt was unlinear anyway). Regarding the interface of the bug reporting I am also with you. It is simply not simple enough for normal users. Too many "knobs". The "problem" is that it is felt that enough bugs are reported anyway, and that therefore, no improvements are needed. Maybe that's correct, but I just can't help to think it is a bit of a strange mindset. //Nicklas
RE: Shuttleworth on Wine
I'd say that attitutudes might change, though. For example, he is mentioning photoshop(of course) which I use at home under win. It works great there. There are only a few quirks with the installation: 1. it need 1.1.17 to work 2. a DLL is needed for the text-tool to work. 3. A winetricks has to be done. When those things are fixed(I guess 1. is the most important), gradually more people will start using wine, hence acceptance will grow, and eventually even Mark Shuttleworth will come around. If I were the leader of the wine project, the moment photoshop CS4 works all the way, that would be the basis of the next stable version(to avoid regessions to the highest degree).. I believe that the popularity of wine(yes, popularity is extra important for a FOSS project) would skyrocket. Then it would be a toy no more. //Nicklas -Original Message- From: wine-devel-boun...@winehq.org [mailto:wine-devel-boun...@winehq.org] On Behalf Of Remco Sent: den 6 maj 2009 01:35 To: Ben Klein Cc: wine-devel@winehq.org Subject: Re: Shuttleworth on Wine On Wed, May 6, 2009 at 1:28 AM, Ben Klein wrote: > 2009/5/6 nn : >> >> And the slashdot thread: >> Shuttleworth Says Ubuntu Can't Just Be Windows >> http://linux.slashdot.org/article.pl?sid=09/05/05/1546230 > > This is nothing new. It's just now we have a celebrity saying it. Not only that. Canonical has decided a few years ago that Wine would not be included for this reason. [1] So it's really really really old news. Remco [1] http://linux.slashdot.org/article.pl?sid=07/05/11/1220219&art_pos=4
RE: Severity levels
>Guys, y'all are going in a circular argument. No need to cc wine-devel >on it anymore. I am rather fed up with it as well, also I will soon not have any more time for it since I'll be going back to work tomorrow. I've had stomach flu(!swine) the last week. Circular? More plain disagreement i'd say. >Let's work toward making normal the default level, and move on with our lives. Yep. Let's do that. Let's aim for the stars. >Any developer/user focus for bugzilla argument is WAY beyond beating a >dead horse. Ok.
RE: Severity levels
>You're one guy against the world. So far, no one on this thread has >responded positively to your proposal to overhaul severities. I'd >suggest you stop acting like it's an inevitability Ok then. >Once again bugzilla is a developer's tool, not a collection of data >for users. We already have the Wiki, forums and AppDB satisfying the >users' needs. Ok. >Point is that metabugs, though useless to users, are important for the >REAL target audience of bugzilla: developers. >Repeat after me: > Bugzilla is there for the developers, not the users Better not let them in then. >A user-centric focus on bug priorities simply would not work with a >project as large (massive?) as Wine is. Repeat after me: "Nicklas Is not proposing a user centric focus, which would be insane, he is merely talking about weighing it in." "Nicklas Is not proposing a user centric focus, which would be insane, he is merely talking about weighing it in." I have actually forgot how many times I have tried to say this. >Then they disappear. There would be no way to search for metabugs, for >example, whereas at the moment you can search for Blockers. There's no >point in keeping metabugs if there's no ... I would search for priority 1 bugs. To be a priority 1 bug it would had to had been either a blocker or critial. Metabugs...well, if they are used a lot maybe that will become a problem. But aren't using metabugs a bit wrong anyway? >You're now implying that all bugs should be given equal priority. No I am not. I rarely imply. >Some bugs *can't* be fixed without limitations lifted in other areas (e.g. >introduction of Xinput2). They could still be severe (mouse-related >bugs could easily attain Major severity) but be a low priority due to >forces outside of Wine. Then severity would be critical and priority 4. > Mixing is up like is done now makes it: > a) more complicated for users. b) more difficult to severity in statistics. >a) is not a consideration for bugzilla. It has to be easy for the >developers that respond. >b) is nonsensical. We're talking about two very different forms of >statistics. Bugzilla is the place for developer-side severity (which >is what's in place now); forums and AppDB are the places for user-side >severity (which is what you're suggesting). By definition, there is no >way to gather statistics on one when the other is used. a) You are right. Keep them users out of there. b) I thought that priority was developer priority and severity was severity for the users. >Please quote with context! And having no definitions of the severity >levels is just asking for trouble. Surely you realise that every user >will have a different opinion on how serious their bug is, and what >the boundaries for "Low", "Medium", "High" and "Critical" are, which >will likely vary greatly from what the developers responding to the >bugs think? Conflict between developers and users is bad, and having >real definitions of the severity levels allows the devs to say "well, >your 'Critical' bug that has a simple but tedious workaround doesn't >fit the definition of Critical, so it's being downgraded to 'Minor'." If one say severity is in usage context and priority is in big-picture context there would be less conflicts. >I can't tell what you're talking about here. Ok. The same. >1) "A few years" is rapid? Yes. I'd say so. I a large project's life, anyway. >2) "Drifting away" from usability when we've always (AFAIK) had the >current severity levels (but not necessarily the definitions), and >established that the system works well to assist developers >categorising the bugs? Wine hasn't been used seriously by people until now. When something goes from being only a toy to a real too it brings changes. >3) "Such a small skew", as in handing over full control over what >priority should be given to the bug to the users? And before you say >it's not "full control", if it's not something that will seriously >influence the way bugs are prioritised, it's pointless to do such a >massive overhaul of the severity ratings. Again, I disagree. Massive? Renaming some categorisations? >4) "Normal" getting fixed more than "minor" is a problem? Yes, this can be a huge problem if minor consists of annoyances. In the end, one have a system that works, but in a very annoying way. >Applications still have to be treated on a per-app basis. Every app is >different, and in extreme cases different versions of the same app use >violently different API calls. Yes, but I am talkic >Correct, games and 3D applications do tend to use DirectX, whereas >office applications don't (tend to). Well done, astute observation. It >doesn't mean that a joystick fix for GTA:San Andreas will work with >Gunmetal, or that a WineD3D patch for COD4 will improve performance in >Supreme Commander. They're all individuals! (Chorus: Yes, they're all >individuals!) They're all different! (Chorus: Yes, they're all >different!) (I'm not) (shhh) I think
RE: Severity levels
>Just changing the default to normal should solve a lot of the problem; people >are less likely to change the severity level if the one they're >presented >with looks reasonable. I think so too. Especially if the selected one, "enhancement" almost certainly is wrong. >I know what Major and Critical mean too, but I can live without being able to >make that change myself if restricting it will help. There's always >the >comment field to state an opinion. I agree here as well. I would also rename "trivial" to "low", "minor" to "medium" and "normal" to "high". *ducks* //Nicklas -Original Message- From: wine-devel-boun...@winehq.org on behalf of Rosanne DiMesio Sent: Mon 2009-05-04 13:39 To: Austin English Cc: wine-devel@winehq.org Subject: Re: Severity levels On Mon, 4 May 2009 00:31:09 -0500 Austin English wrote: > > > > But how would the restriction work? Not that I'm likely to ever submit > > a Major or Critical bug report, but I know what they mean ;) > > > > I don't know if bugzilla supports that or not. > > But changing the default to normal is quick and easy. > > -- Just changing the default to normal should solve a lot of the problem; people are less likely to change the severity level if the one they're presented with looks reasonable. I know what Major and Critical mean too, but I can live without being able to make that change myself if restricting it will help. There's always the comment field to state an opinion. -- Rosanne DiMesio
RE: Severity levels
As I wrote in my earlier post, Austin told me about the voting functionality, and If that is considered when priorities are made, it is likely to keep things pretty on track, making my proposed changes far less important. I still think my thoughts aren't that off anyway, but now they feel a bit more "optional". >No, he's proposing to dump the developer-focused severity completely, >because "component + priority should be good enough", and replace it >with ill-defined, ambiguous Low, Medium, High, Critical. Blockers and >metabugs would also disappear under his proposed model, it seems. >After all, what good are metabugs to users? ;) Exactly. Ben's got it. :-) But blockers and metabugs wouldn't disappear. They would only lose their special classification. They would likely have it's priorities set to 1 by the developer reviewing. In what other way than they are highly prioritized are they different to any other bug? Something that must be fixed, must be fixed, regardless. To me, blocker is a class of bugs, not a level of severity. Mixing is up like is done now makes it: a) more complicated for users. b) more difficult to severity in statistics. >ill-defined I would go further than I'll-defined. I'd say non-defined. The other things I talked about, drifting away from usability is a fairly rapid process(a few years) that I actually have experienced first hand (well second hand, actually), and it wasn't pretty. You joke about it, but the worst thing about it is that because it really only needs such a small skew to happen, it creeps up on you. Because "normal" get fixed far more often than "minor" bugs. > Firefox and IE have drastically different success/failure/issues > when running in Wine, as do MS Word and > WordPerfect Yep, but I'd rather put I it like a Microsoft application has often other problems than externally developed applications(built-in vs using dll:s for everything). Anyway, looking at the forums now, games and 3d applications DO usually have different issues than normal desktop applications. It's more about controllers, DirectX and other stuff. And there are a LOT of posts. 30 new threads the last 24 hours. Lot's to wade through I you're only into D3D issues. If it was different lists, people could become a little bit more specialized. //Nicklas
RE: Severity levels
>I think this argument is circular...Wine has no shortage of bugs being >reported, we have plenty of new users reporting bugs, and new >developers contributing often. You're proposing adding an extra >severity rating that no developer will look at, and will only add to >confusion (users now have to decide *two* levels rather than one). It >won't add any benefit, other than possibly giving users a warm fuzzy >feeling that their bug is 'important' to them (which they can already >do with voting), but adds confusion, wasted time, and wasted effort. Yes the voting! I had forgot about that! Actually that pretty much...lessens many of my previous arguments. Well, turns the into moot, really. I still think that the severity levels could be better with regards to UE though, but that seems less important now with the at least theorethical "me too"-power of voting. Again, sorry for taking your time. Too bad nobody mentioned the voting earlier. //Nicklas PS. I never proposed an extra severity flag, but to change it into something more intuitive for the user. I speculated that classification of bugs could be made anyway. DS.
RE: Severity levels
>>> How many times does this have to be repeated? Severity levels are NOT >>> determined by how much a user wants the app to work. They're just not, >>> deal with it. >> >> I have never said it is, either. >> I said it think it should be determined by how severe the user thinks >> it is(if devs then cares about it is another matter). >And you've already been told it shouldn't, and this has been explained >to you. > >Junk. Explained to me?? ...this is just incredible. Regardless of what I have said, you have repeated almost the same things, it's like you haven't been reading my posts! Leave me alone, I want to talk to someone else. //Nicklas
RE: Severity levels
>Why should there be multiple support forums? Well, not forums, but as I said different lists for different kinds of applications(games/business/graphics), since they should(?) have related problems. I would think so, anyway. >The wiki has _a lot_ of info, most of the time when bugs are closed invalid, >wiki links are given to fix the problem. Again, wine _is_ an open source >project. > If the wiki isn't good enough, add something. I am talking about avoiding a bug being submitted at all. Maybe to organize how-to-run information. Sure I could do a bit of that. It's like the idea you had about getting funding, did they tell you to go do it all by yourself? >How do you mean their priorities are important? It's an uncomfortable >truth, but users priorities aren't important, like has been said >dozens of times. Sure, we care about user's bugs, and want to fix >them. ... Users priorities probably affect what severity level they choose. But as I said to Ken, I can't believe that all users are morons. Anyway, regardless of their motives, I still think that they have to be included. If not, the project will slowly drift away and turn into a toy nobody have any use for. >But every user also thinks *their* app is the most important >application to fix. Actually, I can't believe they all are that way. When I first posted a bug here on bugzilla some time ago, one of the first thing I got was you telling me that "there are other applications just as important as yours". The reason in my case was that I completely misunderstood the severity instructions (I had the flu so I was a bit hazy) and mixed it up with the priority instructions. I got going on your comment that Photoshop was not more critical than any other application, which I a far cry from getting pissed of about something with really few users. >Wine can't stop development on _everything_ just to get one user's >application running. Making user's arbitrary priorities the most >important would be doing this. Good thing I didn't propose that then. :-) I said it should be a part of the priority and a considerable one. Not the largest one. And I am not talking about users arbitrary priorities, just including more intuitive severity levels(good or bad) when making bug fixing priorities. //Nicklas
Re: Severity levels
>How many times does this have to be repeated? Severity levels are NOT >determined by how much a user wants the app to work. They're just not, >deal with it. I have never said it is, either. I said it think it should be determined by how severe the user thinks it is(if devs then cares about it is another matter). You seem to be convinced that all users are morons hyping their own stuff. >>>If a set of devs decide to work on getting a particular app working >>>that's up to them, and we've already been over this too. >> Obviously. I can't remember opposing that? >Who said you had? Why writing that we've had already been over it, then?!?? .etc "you can't see the picture" .etc "Not to you, no. Only what you think is right." .etc Huh? This doesn't lead anywhere, you constantly misread me and I don't seem to understand what you are getting at. For some reason, I seem to annoy the hell out if you. I really don't get it, it is not my intention. Do I have some kind of attitude I need to be aware of? I am not a native English speaker. Anyway, it has been obvious from the start that you and I can't communicate. Therefore, I am backing out(hands in air) of this discussion before...uh.. after it has gotten out of hand. //Nicklas
RE: Severity levels
>No it isn't. It's an indication on how many people think they're more >important than anyone else filing a bug. I think that you are wrong. Granted, some people do, they are called morons. But most people aren't morons. They are people, and to them, the issue really is critical. At least they think that. Give people the benefit of the doubt here. >It doesn't matter what the users think, we've been over this, it would >be up to MS coders. >They would put a high priority on it because Adobe it a major player, >and I'm sure MS makes a lot of money out of them one way or another. >This is a FOSS project and has no bearing on severity levels. So Photoshop has not been the least prioritized? I don't think you paint the entire picture. >If a set of devs decide to work on getting a particular app working >that's up to them, and we've already been over this too. Obviously. I can't remember opposing that? >Bares no relevance whatsoever to severity levels in Bugzilla. Nothing does, does it? //Nicklas
RE: Severity levels
>So you suggest making the severity ratings meaningless to anyone but >... well, you don't actually mention anyone knowing what they *really* >mean, but I assume an exclusive clique of developers or bugzilla >admins? Users have different opinions on what level of bug they >encounter depending on what *task* they're trying to perform, which is >not particularly useful to developers who need strict reproducability. No, I mean that the actual meaning of the words "low", "medium", "high" and "Critical" will suffice. I think most people have a fair understanding what "medium" and "critical" means. This is not meaningless at all, to trying to clarify these levels is quite pointless though. Yes, some people tend to exaggerate their issues, but that's just the way it is. And to my experience, they are few. Most actually don't exaggerate as much. To them, the situation IS critical, bordering on panic. Rather, thinking that their users are exaggerating is a way for developers to not let reality come to close. Hell, I do it myself right now. :-) I don't see how the reproducibility connects to the severity level? Regarding the priority flag..i was referring to it's visibility, not its state. >There already is a separate category flag. It's called "severity" and >it indicates roughly the amount of *functionality* lost due to the >bug. "Priority" does not indicate the severity of a bug; a bug may >have low priority due to limitations outside of Wine (such as some >blocker bugs for copy-protection systems which can't be supported in >Wine). My point is that there should be no need for that flag. Let the users have it as input, and let the developers use component+priority. >You're not going to like this, but users don't matter quite *that* >much on bugzilla. The bug tracker is a developer's tool, and although >users are essential to the process (submitting bugs and new >information on request), it should be designed as a developer's tool. >A user's impression of their problem is irrelevant to the hard data >they can provide about lost or missing functionality. You are right. I don't like it. Especially because the bug tracker is the entire projects tool, not only the developers. I this matter can only compare with my own professional(commercial) experience and there, the ones submitting bugs has a *lot* to say, since they won't submit bugs unless they are critical if we don't present them with a smooth interface. Hmm..only critical bugs..now where have i heard about that..? :-) //Nicklas
RE: Severity levels
>To every Wine user, their application not working is critical. This is >clear by all the bugs that are logged incorrectly every day, because >nobody bothered reading the FAQ. Yep, but that's more an indication on how much work remains to be done on wine than it is an incorrect severity level. If Photoshop(the eternal example) should stop working on windows due to a regression, I am sure the users would consider it critical when they report it to Microsoft. But as the wine project progresses, severity levels will hopefully drop so that there will be more nuances. I just think there is something severely when registering a bug that results in unworkable applications is considered a "normal" or even "minor" bug. To me, that's sending the wrong signals about the ambition of the project. Unless the "not yet suitable for general use" from the faq is everywhere with blinking warning signs. //Nicklas
RE: Severity levels
>I disagree. When first introduced to them, I found the severity levels >to be suitably vague to make me read the definitions. Once I read >them, it was clear to me what each level means. Suitably? Do you mean that the severity levels are the way they are to make people read their definitions? :-) Jokes aside, that's exactly what I don't want. I want them to be even more vague(Low, Medium, High and Critical) and without any definitions except for the highest level. This way, one will elicit more how the user perceives the overall impact of the bug, without having to shoehorn them into some level that only partly matches their impression. Done with the help of the users indisputable "common sense", of course. Also, the priority flag should not be visible to the user by default, it should be a strangely named setting somewhere in the user preferences. >But bear in mind the severity levels are there >to help the developers categorise the bugs, and they are not there to >provide feedback to the average non-coding user. For categorisation, there could be a separate category flag if the "component" categorisation + priority wouldn't suffice. Whatever. There are many ways to do it. But currently, the users' impression of the problem get lost and/or skewed. //Nicklas
RE: Severity levels
> You'd be surprised... We'll I've looked around at "invalids", but to me it seems that people in general(with a few exceptions of course), tries quite hard until they file a bug report. At least way harder than they do in other FOSS projects I have been involved in, so I can't really say that I would think you've got a problem. At least not yet. Despite the support forum only have one list. More stuff on the wiki would help too. >Not all critical bugs are caused by the loader. It's possible for >d3d/ole/etc. to have a similar effect. Yes, it is possible, but not likely enough to warrant an extra severity level. Yes, I have looked. >Keep in mind, most developers are unpaid as well. They're the ones >fixing the bugs, not users. While users are important, no work gets >done without the developers. I know that most developers are also unpaid. With "maintained" I didn't only mean maintainers of versions and so forth. >Developers have no way to prioritize one >user over another. The best way to prioritize *your* bug is to make a >*good* bug report. Make sure all needed information is included. Get a >testcase if possible. Provide the needed traces, etc. Even better, is >to write a patch yourself. The source is there, and there is nothing >stopping you from writing a patch. Again. This is not what I am talking about. I am not relevant because I am also an experienced developer, so I have no problems with these things. I can patch like there is no tomorrow, given time. What I am talking about the fact that the ordinary users priorities are very important. Currently they are either: 1.Completely disregarded or 2. If they follow the instruction(where "commons sense" is not mentioned), they're forced to adhere to severity levels that distort or hide their opinion of the problem. And for each user reporting there are dozens that are not. Bad will. It just feels like the entire project should become a bit more user-centric. Now I am not just talking about shinier graphics but about attitude. Maybe soften up a bit ask oneself, "WHY did this person ask this stupid question?", "WHY did he do this EVEN though it says do this?" or "How would I feel if someone said this to me?". //Nicklas
RE: Severity levels
Ok..you seem to have misunderstood the tone in my mail. >Without common sense, all bug reports would be "Enhancement" requests, >or "Critical", depending on how arrogant the reporter is. Common sense >must *always* be applied. I should be needed to be applied only to the least possible amount. One should never have to think for no reason. The more "common sense" that have to be applied to make something work, the less something works by itself. Of course, you can't completely do away with common sense. I said "without common sense" to point out the problems. And, well, some have less common sense. Or a different kind. Or are just tired, stressed out or something else. So, the less common sense needed, the better, IMO. My other point is that reporters are like to become less technical. > Oh, and use "Reply to all" so you stop just hitting Austin with responses! Huh? The mailing list is cc:d, Isn't that enough? I mean, it looks on you mail you mailed me and cc:d? Doesn't the mailing list propagate messages if it is only cc:d? Have I misunderstood something? In that case I am sorry. >Rosanne is an AppDB admin. What contribution have you made to Wine? >Out of you and her, I don't think her credibility can be called in to >question. And before you ask, I'm also an AppDB admin, I package the >Debian packages for WineHQ, and have had a patch committed to Wine. >I'll even send you the git revision code if you can't find it! :D >Note that like Rosanne, even when I was a newbie submitting bug >reports, I understood the severity levels because I read the >descriptions. The descriptions are fine as is, with the possible >exception of "Blocker" (people submit "Blocker" bugs for "Normal" >issues because it blocks the thing that they're doing). It's seems you missed the ":-)". I put in the end of the sentence on credibility. It was a joke and she seems to have took it that way, since she joked back. With regards to the severity levels, to me, none of them means what one would think they do intuitively. //Nicklas PS. I am sorry if I have broken the rules of this list, but I thought I followed them. I hope you don't let this detract from my arguments. DS.
RE: Severity levels
>I think "middle-aged college English teacher who couldn't code if her life >depended on it" counts as non-technical. :-) The only thing that sets me >>apart from most users is the fact that I actually do RTFM, but that's just >because I'm one of those eccentric academics who thinks reading is a >really >good way to learn. Reading? But you are going to end up all cross-eyed, dear? Everything I know about programming I have learned from stories my parents told me as a kid. And they heard them from their parents and now I am passing it on to my 3-year old daughter. She is very much into the older Windows API:s right now and just wants to hear that story about oleacc.dll again and again and again.
RE: Severity levels
>The problem is, however, that many of those problems only break an >application or two. What is a blocker for Photoshop isn't a blocker >for World of Warcraft or Microsoft Office, for example. You mean because Photoshop often use the more obscure parts of the APIs? Otherwise bugs in GUI shouldn't be less contagious than other kinds. Unless one regards UE issues as less severe, that is... :-) Anyway, I fail to see how this connects to the severity level discussion? >Please bottom post on wine mailing lists. Yep. But I was top posted earlier so I got confused. Also I am in a crappy exchange web mail client.. I hope you managed to read this post better. //Nicklas
RE: Severity levels
Not applications, issues. My point is that user experience issues gets a lower severity than they should. Let's take photoshop CS 4 with two old but relevant actual issues as an example. 1. There is a problem with the text tool functionality, it did not work. Everything else works, though. 2. There are serious graphics problems, huge artifacts, the entire application is almost unworkable under Gnome. With the current severity levels(without common sense), example 1 gets higher priority, which I think is wrong. //Nicklas PS. Yes I know the actual issue turned out to be a configuration thing. But that's not the point. DS. -Original Message- From: Austin English [mailto:austinengl...@gmail.com] Sent: Sat 2009-05-02 20:56 To: Nicklas Börjesson Cc: wine-devel@winehq.org Subject: Re: Severity levels 2009/5/2 Nicklas Börjesson : >>Wine is meant to support _ALL_ windows applications. It doesn't give >>priority to 'server' or 'desktop' applications (there is no >>difference, really), but instead tries to make all of them work. > > Yes, but I wasn't talking about server applikations per se, but that the > severity levels would be perfect for a server application, hence skewing the > priorities away from GUI and other, more "soft", user experience issues. I'm curious what non-gui applications you're talking about in regards to wine. -- -Austin
RE: Severity levels
The normal user doesn't even understand that the definitions should be read, most people think they know what "trivial", "minor","normal","major" means anyway. I actually discussed this with some friends recently. I just think that it could be more user-oriented. Non-technical? Posting on and following the wine-devel list? Severity levels perfectly clear? I must say, you've got some serious credibility issues.. :-) //Nicklas -Original Message- From: Rosanne DiMesio [mailto:dime...@earthlink.net] Sent: Sat 2009-05-02 19:09 To: Ken Sharp Cc: Nicklas Börjesson; wine-devel@winehq.org Subject: Re: Severity levels > > This is way easier to understand for normal people. Speaking as a non-technical user who does file bug reports now and then, I have always found the definitions of the severity levels to be perfectly clear, even when I was new to Wine, and from what I've seen, when a reporter sets the wrong severity level, it's usually because they didn't bother to read the definitions in the first place. -- Rosanne DiMesio
RE: Severity levels
>Wine is meant to support _ALL_ windows applications. It doesn't give >priority to 'server' or 'desktop' applications (there is no >difference, really), but instead tries to make all of them work. Yes, but I wasn't talking about server applikations per se, but that the severity levels would be perfect for a server application, hence skewing the priorities away from GUI and other, more "soft", user experience issues. I am not specifically talking about Photoshop, either. I am talking about all GUI-centered applications. Yes, I read about that, huge kudos to Google for still being benevolent(and Dan of course). But. Listen. I am not here to try and get Photoshop CS 4 fixed, that's already done, it works great for me. It's just that I have some ideas on what I would think would be simple but effective changes of the bug reporting and don't give up easily. :-) //Nicklas
RE: Severity levels
Ok, I have made better posts. >> 1. Blocker "Blocks development and/or testing work" >> >> - Is this even possible? >Yes. I am sorry. Of course it is possible to have these problems. I thought it meant that it blocks ALL development and/or testing work(since it is above critical). In the list, there are mostly platform-specific issues. My mistake. >> 2. Critical "Critical problem that prevents all applications from working" >> >> - Possible, if everyone stopped testing code completely, and also unlikely >> to be reported by a user. >No, critical bugs are usually opened by non-Linux users. Here I did search, and actually, most bugs have "linux" as an operating system so I couldn't come to that conclusion. Anyway, I get your point. Still don't really see why this is a separate severity level, though. Wouldn't this be a "wineloader" component or something? >> 3. Major "Major loss of functionality for a wide range of applications >> >> - Isn't this just all bugs that has more than $arbitrary_number of >> applications linked to them? An aggregate, >> rather than a level? >No, it's actually what it say, a WIDE RANGE of applications. Ok..I just thought that "wide range" could be translated into a number or percentage instead of an expression. I thought the opposite way...but couldn't possibly all bugs in wine affect a wide range of appliacations? > Bugzilla is to track bugs, it's not a user support forum, and the bugs > should be classified as the dev's want them to be classified. No, I know it is not a support forum(Is users using is as such a big problem?). But it is nevertheless an interface towards the users of wine. A place they go to when all else has failed(hopefully). And as such it is utterly confusing(for them) and already leads to pointless misunderstandings and frustrations regarding, for example, the severity flag. Anyway. I can't help but feel that we are on completely different pages in many ways. I think that the users should have quite a say with regards to how important a bug is, because for every user putting in the (considerable for a user) effort of reporting a bug, there are dozens that don't say anything at all. In wine's case, because of it's size, this might actually be hundreds. It's badwill. So currently, there is no way at all for users to influence these priorities. To me, user priorities would be a considerable factor, obviously not the only one, but considerable. I know that wine, to a large extent, Is maintained by unpaid individuals(like myself) that want to prioritize themselves. I don't want to take that right away from them, I just feel that it's bad practice to disregard the users' priorities. //Nicklas PS. >Your line length needs fixing. I have to admit I sent this using my employers horrible web mail (no idea why it says 6.5 though, think it is 2005). We will pretty soon "exchange" it, though. :-) DS.
RE: Severity levels
I am not sure that common sense is the issue. I think it is a question of who you are and what you know. Among the ones submitting bugs now is a quickly rising percentage of normal-to-advanced end users, and that percentage is likely to rise even further, as Linux adoption rates increase. 10 million desktops is the last number I've heard..and people are learning how to report problems. Hell, my mom(77 years old) reported a bug a while ago. My point is, why not adapt the severity levels to the competence level of the submitters instead of having to correct them all the time, creating badwill? Can't the three highest severity levels just be removed? Are they relevant? 1. Blocker "Blocks development and/or testing work" - Is this even possible? 2. Critical "Critical problem that prevents all applications from working" - Possible, if everyone stopped testing code completely, and also unlikely to be reported by a user. 3. Major"Major loss of functionality for a wide range of applications - Isn't this just all bugs that has more than $arbitrary_number of applications linked to them? An aggregate, rather than a level? Then, the severity(or "impact") levels could be: Critical High Medium Low This is way easier to understand for normal people. Also, the definition of each level should not be all that clear(except maybe critical) either, the levels will be discussed anyway, so it is easier to motivate for the developers to grade down a bug without too much discussion. Because the more people start using wine to actually make a living, the more important it will be to them. One would think that vague levels would create more discussion, but according to my experience, and with end-users, it seems to work the other way. And yes, I know that the bug reporting system is used by the developers internally as well, but do you really use the first two levels so often that you need them(I hope not)? //Nicklas
Severity levels
Hi all! First, I couldn't find any list more suitable than this one to comment the severity levels in the bug reporting so I post it here. If this was a really bad thing to do, please tell me were to do so. Secondly, don't take this wrong, I am not here to preach, I actually think this is a serious problem. I am not drunk either. Currently. :-) So, with regards to severity levels: Current severity levels are perfect for server applications where everything is simply about functionality working or not working. However, the overwhelming majority of windows applications in general, and those being ported through wine in particular are GUI-based, end-user applications. When it comes to these kinds of applications, in front of which actual people sit for hours on end doing actual work, other factors come into play. So I would like to introduce a bold new weight into the severity assessment: The user experience. Or at least the bugs' negative impact on it. The user experience(UE from here on) is really quite impossible to quantify exactly, luckily that is not usually necessary. There are several reasons to incorporate this into the severity classification, but I'll stop at two: 1. The ones reporting the bugs will come across with how severe they think the bug is to them. Currently, there is far too much of "you've got a almost black screen or black square instead of icons running Photoshop?..hmm that's really trivial...an 'UI glitch', but OK then, I'll mark it minor to be nice to ya." To a user, even an advanced one, this must feel like talking to a condescending Martian. Frustrating, if not infuriating. Likely, they will never again take the time to make a bug report. It is even quite likely that they will give up their move away from windows. 2. Currently, fixing a "trivial" UE-bug can make way more users happy than fixing a "normal" functionality-bug. This means that bug fixing is prioritized on a basis other than catering to the users needs. And to me, that's something that really shows. Can one defend this without invalidating the wine project? It is a serious question, I might have missed something fundamental. Anyway, I have some ideas on how to make the severity classifications better(and more intuitive for the mere user), but I won't go in to that now. I just want to know if any of you agree with me. Do I make a valid point? //Nicklas PS. I repost this since I didn't get any post from the server the first time. Also I expect this post to piss some off, which makes it even stranger not to get any replies at all. BTW, I also just read in a comment in a bug report that the severity flag doesn't mean much at all when it comes to how a bug is prioritized. So the only input the users have on how important a bug is to them is practically ignored? Why have that checkbox then? And why make such a big thing of it not being correctly set? DS.
