Hi, David Neary <dneary@xxxxxxx> writes: > From my perspective, I've seen discussions in recent months on > modifying shortcuts to conform with the HIG, reduce the > complexity of the install process, setting the menu on the image > windows on by default, and on and on. There have been 4 or 5 of > these arguments and in every case your position has been to stick > with the status quo. People have said to you "users find this too > complex. I find this too complex." and your answer has been "Some > people find it useful". In most of these points that were discussed we did change the code in the end. It is unfair to say we would not allow changes. Unless a change is obviously the right thing to do or very well argumented, it is my politic to first oppose it. I do this to enforce that the reasons for a change are outlined and that advantages and possible disadvantages are outweight. It is often easy to do a quick change but very frustrating to undo one, so every change should be evaluated before it can be done. > Up until quite recently (that is, during the first 2 years of 1.3 > development) anyone who wanted to open a bugzilla report against 1.3 > was told they couldn't - that the series was unstable, full stop. This is not true. We did so for some parts that were undergoing a total rewrite but basically we have accepted every bug-report since version 1.3.0 was released. > As you say, I am not subscribed to the user list. Perhaps I > should be. I suspect I'm not alone in not subscribing. But the > idea of the separation of lists was that I didn't have to be. > Perhaps that day is gone, and I should just subscribe to the > user list and be done with it. In this case, if all the > developers are subscribed to the user list, why would we need > a devel list? So that the users stay on the user list and don't get shyed away by developers discussions. Please note that this is just an argument. As usual I'm not completely against your idea, I only mention the possible problems I see. >> > 1) Not enough users use bugzilla to report bugs >> >> Bugzilla is the only way to report bugs. Whooever reports bugs uses >> Bugzilla for it. A few people need to be shown the way to it but in >> the end everyone uses Bugzilla. > > Bugzilla is a quite complicated tool. I love it. As you say, > anyone who reports bugs uses bugzilla. That means we miss lots of > bugs. I totally agree but since we already have a very hard time to deal with bug-reports that come in thru Bugzilla, I am strongly against any change that would cause an increase in work caused by bug-reports. Everything you say about Bugzilla is completely right but I don't see how you want to improve bug-handling w/o increasing the amount of work they cause. > "Use bugzilla" != "add occasional comments to bugs and maybe fix > a few". As I'm sure you've noticed, 90% of comments on open gimp > bugs are from either yourself or Raphael. Surely not because I ever discouraged anyone from helping out here. Or did I? > Not no-one is using it. I use it to do a quick filter on bugs I > might find interesting. I delete 99% of the mails as they arrive. > I actually use this more than bugzilla (where "using bugzilla" > means getting ownership of bugs, and fixing them or passing on > ownership to someone else). That is what I meant. No-one reports bugs thru it. Of course it is used but only as an important interface to Bugzilla. > Now, let's look at the "Owner" field - 1 bug is owned by > grosgood, one by jimmac, 2 by mitch, 2 by Raphael, 2 by rockwlrs, > and 1 each for sven and yosh. That's 10. Leaving 381 bugs owned > by that well-known gimp developer bugs@xxxxxxxxx All bugs that are not owned by bugs@xxxxxxxx have been accidentally reassigned. We simply don't this field, it has no meaning. Of course we can discuss to change this but counting these numbers doesn't make any sense at the moment. > The lifecycle of a bug *should* be that a bug gets reported > against a module, which is owned by the module owner, who knows > who works on what parts of that module (for example, a bug > against the plug-ins module would land in the mailbox of someone > who knew that adam owns the psd plug-in, but that myself or > Maurits might be interested). This person doesn't need to be > technical, they need to be good enough to screen out the > NEEDINFOs, the NOTABUGs, the INVALIDs. Otherwise their job is to > turn unconfirmeds into news, and to pass the bug on to the person > (or group of people) interested. We use the Cc: field for exactly this purpose. It is more flexible than module owners since we would then need a component for each and every plug-in. > At this point, the person to whom the bug has been assigned > either accepts the bug (effectively agreeing to fix it), or > re-assigns the bug to someone else. When the bug is fixed, it is > reassigned to the original reporter for verification and > eventually closure. Yes, that's what they told me in the QA classes as well. I am not sure if it is really doable with GIMP. But sure, ideally it would work that way. > That is what is supposed to happen in bugzilla. What actually > happens is kind of similar, in a haphasard way. Usually a bug in > one of the file format bugs gets adam's email stuck onto it by > someone, and he ends up having a look. Or I notice a keyword in a > mail I get at bugs@xxx that might be related to a bugfiw I > botched up. And so on. I had the impression this was working reasonably well. Ask any customer of a commercial-grade software application about the response time for bug-reports and quality of support. Then do the same with a GIMP customer. I don't think we would look bad in such a comparison. > Where do you see any mention of bugs, or support, or anything a > user might be tempted to follow in the event of a problem? > > I thought the mention of scrolling above made it clear what I > meant... Come on, it's on the front-page, it's even there w/o scrolling on my desktop screen. > Hopefully this will develop a bit more and people's positions can > be cleared up before camp, I would like to spend some time at the > camp discussing these types of issues (communication, and > distribution of responsibility). Of course, if we can all agree > before camp, great. More time for beer. All your proposals sound perfect but I have my doubts how well they would work in practise. It's not that we wouldn't have tried to get more people involved and to spread responsibility. Sven
