Remember when people tracked bugs?
jwz.org
jwz.org
Typically they'd be ignored, fixed several months later if I'm lucky[1], and still ignored as they get closed by an automated bot[2]. Chrome specifically created an "icebox" to automatically close old bugs.
I'm convinced that the Chrome team at least has an internal bug-tracker they use and the external one (crbug.com) serves the same purpose as fake thermostats on the walls of office buildings.
(To Chrome's credit, they took the only security bug I filed very seriously and fixed it in a couple days.)
[1] Unlucky: Still an issue with broken translating gradients in non-hardware-accelerated canvas: https://bugzilla.mozilla.org/show_bug.cgi?id=774387
[2] This bug was ignored, fixed, and for a year I asked for it to be closed. It was finally closed by a street-sweeping bot: https://code.google.com/p/chromium/issues/detail?id=62373
In the old days I (and a few friends) personally reviewed every bug marked "Linux" and we attempted to triage them, but at one point I realized bugs were filed faster than we could classify or fix them. That isn't saying new bugs were being introduced rapidly, but rather that there's a lot of random spam ("my site doesn't work" / "does it work in other browsers?" / "no") and not-yet-implemented feature requests that appear to users as bugs.
The latest bug on the public tracker is bug number 174163. Chrome was released in late 2008, so let's round up and say the tracker's been up for five years. That's averaging nearly 35k bugs a year, or 95 a day, and in reality the rate was slower in the early years so it's much faster than that now. Even just reading each bug and understanding whether it's reporting an actual issue takes hours.
I have come to believe that a publicly writable bug tracker is a bad idea. Something like what SQLite does (where once users must first establish via some other mechanism they know how to file useful bugs -- yours look good at a glance, but I'd recommend attaching the demo html to the tracker so the link doesn't eventually 404) likely makes a lot of people mad but at least they're not shouting into a vacuum.
Recently (like in the last few months) I heard they've allocated more resources to looking at the tracker, so maybe things will improve. It's honestly just a hard problem.
That honestly doesn't sound too scary. I did QA for Opera for a few years, and triaging (for specific platforms, at least) is remarkably quick after a while. A glance and a quick test on two platforms should let you toss a bug in either of four bins:
a) WFM/invalid/bullshit
b) Duplicate (it's scary how many bug id's you remember after a while)
c) Likely a core/cross-platform problem (somebody else's problem)
d) Worthy of further investigation
Provided that you have some sort of bucket in which to toss the cross-platform/core bugs, only the bugs in category d should take longer than a couple of minutes each to triage. Some would argue that bugs in category d are already triaged at that point and should be put in some ANALYZE bucket.
Most bug trackers worry about how best to show you a list of issues, the thing is if most of those issues aren’t reported correctly they’re useless.
We’re currently trying to resolve this problem for web devs specifically by creating an embedded tracker, where you integrate the bug reporting directly into a site or web app. Meaning people can report issues in the way that’s natural for them e.g. "this is broken" and the tracker handles capturing all the other data a dev needs to verify and fix the problem. Our app can be found at http://www.bugherd.com if it’s of any interest to anyone.
For a high-volume end-user project like Chrome or Firefox, a wizard/flowchart type UI probably ought to be the default, with a more streamlined UI available to people who have been approved by admins or met some criteria programmed in to the system. An example of the process a user might go through is:
What's the problem? -> A web page doesn't look right in Chrome -> Have you tried it in another browser? -> No -> What other browsers do you have? -> None -> Ok. Here's a list of browsers that run on your OS and where to get them -> Firefox -> Ok, does it look right in Firefox? -> Yes -> Do you know how to take a screenshot?
And so on until the user has likely provided enough information for a good bug report. There could be short-circuits in the process - for example, when asking if the user has tried another browser, a small link a bit outside the main UI could say "I've tried another browser and I have screenshots from both".
After all it's just a question of man power to remove duplicates, prioritize by commonness and make sure long-term bugs really get fixed. That latter has the advantage that the code base really gets improved.
In fact the Ubuntu project seems to do something similar eventhough it is IMHO not well enough organized: there is ubuntuforums.org, when I recently asked a question there, within minutes I got a response. The response was not helpful at all but still. The moderators were really doing a lot to keep the forum organized, and for instanced pulled me into a separate thread to not spam another bug. (Which was in their opinion a different issue.) Taking this a step further and bridging it with the actual Ubuntu bug tracker on launchpad would be awesome. Maybe with launchpad having only limited write permissions for the public.
Google sometimes give me the impression they want to absolutely only hire the best engineers, but I'd argue that many non automatable tasks can be done more efficiently by having some reasonably trained lower rank staff. See also all the complaints about missing service when trying to use Google products commercially - if they do want to seriously enter that market, this stuff needs to change significantly.
Other things that come to mind: Automated Youtube takedowns and Gmail account blocks. Do you really want to save those few million bucks a year for not hiring support staff, then have lots of disgruntled users blogging about how evil you are and then pouring those millions into PR campaigns?
Yes! But, in my comment I pointed out a specific example of where you lose a potentially valuable report.
We really need a way to reset those bug report counters to zero in one fell swoop.
The solution, of course, is planned obsolescence.
Bonus: http://xkcd.com/844/
I think the thing that frustrates me the most isn't the bugs themselves. After all, in general for OSS I'm not paying anyone to make or fix things, and they owe me nothing.
What irritates me is when high-profile projects like Chrome and Firefox (coincidentally both browsers, but that's not my point) then promote themselves as serious, professional-standard projects that people can rely on. They and their evangelists take great pride in stealing market share from established closed source/commercial alternatives (IE in the browser case). Then normal people start using them, expecting a better experience. But then every time there's an update, we play the "will my software even still work?" lottery. (And this applies not just to the browsers, in that example, but also to all the web apps running on them, for which users might be paying real money.)
Unfortunately, on the kinds of geek-friendly forums where these movements tend to start before they expand to the general population, it's often sacrilege to criticise a favoured OSS project. You may get hostile replies, or simply voted into obscurity by whatever mechanism is in place, even if like jwz you take the time to cite specific problems or have provided detailed bug reports and test cases. (Doing the latter is absurdly difficult for many of the large projects anyway, but it gives them a convenient excuse to ignore problems.)
Again, it's completely up to these projects whether to promote helpful contributions or to be hostile. They're giving their stuff away, and owe the rest of us nothing. But it would be nice if there was a little truth in advertising. If an OSS project isn't going to take bug fixing or regression testing seriously, it shouldn't promote itself as professional standard software. (And if a project is created/maintained entirely by one amazingly generous person running the whole show but who has limited time to devote to the project and can't keep up with everything, it would be helpful if there was a prominent warning to that effect somewhere people considering that project would find it before they started relying on it unwisely. Perhaps that would even prompt more concrete support and/or contributions to help the project out.)
I don't think that "closed source / commercial alternatives" (IE in the browser case) have done any better on the bug side than the open source ones.
One of the reason people use OSS is that -despite all the flaws that JWZ points out about the bugfixing process-, bugs have historically been fixed faster and the community support is (again, on the average and historically) more responsive.
So the received wisdom would have us believe. The thing is, my bug trackers objectively say different.
In the past 12 months, I have seen exactly one serious bug in IE (where I define "serious" to mean that user-visible functionality in at least one web app I've worked on does not work properly, even though the same functionality worked in earlier versions of the same browser and/or works in multiple other browsers). That one may have been IE's fault or it may have been a problem with a Java update, since the bad behaviour was at the interface between JS and Java and both had recently had updates when we started to see the problem.
In contrast, I have seen serious bugs in Chrome in every web app I work on, ranging from another Java integration issue through to messing up HTML5 video. Several of those bugs still haven't been fixed several update cycles later. Statistically, across all the projects I'm working on -- which since I'm doing various freelance work and running multiple businesses have little in common except for all being web apps -- it is clear that Chrome is by far the flakiest browser at the moment.
Firefox is actually faring slightly better lately, though as a Firefox user rather than a developer they still keep making usability screw-ups. I get that there have been a couple of critical security issues with Java recently, but since Firefox itself patches at least a handful of critical issues every release cycle I think the "Don't use this, run away, it's scary!" treatment is frankly rather childish. And as of version 18, Firefox frequently seems to corrupt the display of text areas like the one I'm typing this in.
I don't like to be negative about software since nothing's really perfect in this business, but I do point the finger squarely at the advocates of six-weekly releases on this one. The quality of Chrome has never been that great and it's always suffered from "UI rearranging itself at random" syndrome because of the silent updates. However, the quality of Firefox has nose-dived since the move to a rapid release cycle; I'd estimate we're seeing 4-5x as many minor issues in Firefox across all the projects I work on since that happened, plus a couple of howlers like the plug-in screw-up in the first so-called long term support release.
The only time I've had issues with chrome, is when I switched to the dev stream... Stable has always been, well, stable.
In Chrome's case, the most obvious changes lately always seem to be adding junk like apps or a web store or logging in (logging in... to my browser... yes, really). I have no need of or interest in any of these things, yet they now clutter up the UI where once they did not.
If you can't back up your argument with something substantial, then don't mention it. Automatic updates are an actual feature of Chrome and for a good reason. I wouldn't call updates "rearranging the UI at random". And the rest is also complete useless, because your "bug" essentially is that Chrome changes. Well duh!
You might not like logging in to a browser, and I can see the point. But that is not a bug in Chrome.
No, and I didn't say it was.
The bugs I was talking about are things like stopping playing a short HTML5 video before reaching the end, or failing to send basic event notifications to JavaScript before handing control off to the Java plug-in because the user interacted with an applet. Both of these are regressions in things that used to work, and they fundamentally break the behaviour of web apps using those features.
And of course, there have also been numerous rendering problems with everyday CSS in Chrome: banding in linear-gradients, inability to use fractional letter-spacing, I've lost count of how many attempts to get border-radius working properly, etc. These are what I would class as cosmetic issues rather than "serious" ones that actually break functionality like the ones I mentioned before, but they're still things where Chrome is coming in a fairly poor third place in quality of implementation today.
None of these is exactly a big secret or somehow overlooked in the Chrome and/or upstream bug trackers, as a quick Google search for any of the symptoms I've just mentioned will rapidly confirm. In fact, the letter-spacing one was first reported in WebKit Bugzilla more than four years ago and remains unfixed today.
Granted, web browsers are a special case, since you can't patch everyone's Chrome and Firefox and Opera, but for every other type of software it's another strong incentive for OSS.
One way they prioritize bugs (I believe) is by the number of times the bug has been starred.
I do not believe they have separate bug databases. They do have the ability to mark bugs private, which afaik is only used for security issues.
Examples:
https://bugs.webkit.org/show_bug.cgi?id=32303 https://bugs.webkit.org/show_bug.cgi?id=35472
I hate to pester people who are already working on other things, but some bugs just need to be fixed at the browser level.
It also helps to attach a reduced test case and as much information as you can glean about the bug so that it can be reproduced.
And as you say, there is a point as well to go on IRC and ask. :D
It's worth noting that many of those thermostats aren't "false", but just have their control disabled. That means they still provide current temperature information to determine if heating needs to be activated.
Before you start using an OS project for anything serious, take a look at their forums, bug databases and repos.
Is there active discussion from more than 2 or 3 people? Are there regular commits? How are they handling bugs?
I've considered open sourcing code that I have written in the past, mainly stuff I built for one project where it serves the purposes of that project fine. In such a case handling bug reports from users trying to do different stuff with it would realistically just be a low priority.
jwz rants always make me feel that the author is somehow bitter about the world not revolving around his needs.
I'm one guy with a side project (http://gmsl.sf.net/) and I try to fix bugs and add features when they come in. I've been maintaining it for years.
The main thing to do is decide if you are going to maintain something, or if it needs to be handed over to someone else. I did the latter for POPFile (http://getpopfile.org/) which is handled by a small team of people since I no longer had the energy or time to maintain and improve it.
It always scares me when I'm working on a project that has accumulates a dozen dependencies on various people's github repos, that may or may not actually be maintained or stable.
If the code does what you want of it, you have saved considerable time not having to write it yourself. If it proves to have bugs/compatibility problems in the future, then you can fix those issues, just as you would have to do if you had written it yourself. It is rather unlikely that your attempt at the problem will yield any better results over the long haul, so maintenance is a fact of life either way.
If a project is actively maintained by someone else, that is just an extra sweet bonus.
It comes down to friction: even if your system is better, it still means I need to learn your system before I can usefully contribute. If you're using a well-known system I'm much more likely to bother contributing back.
There is nothing major in those pull requests/issues, but they are ignored. This project is great for what it does (lets you parse cron schedule input and gives you a datetime of the next execution), but the author seems to have abandoned the project. Now I am left with a difficult choice of using the project as is, or forking it and and making my own changes. If I fork it, I then have to monitor whether the upstream author shows up again and then I have to figure out what to do about his/her changes.
If anything GitHub makes it easier for someone to half-ass a project and then abandon it as it is starting to get popular. Places like SourceForge had some vetting that may or may not have prevented this type of thing. GitHub works well for projects that have lots of contributors, but for a "small library that does X" it becomes a graveyard.
It is simple, you see a project you like. If it has a bug you fix it in a fork. You use the fork until the project lead responds to your pull request. And if the project leads response doesn't suit you, you just continue to use the fork, you can pull from the original project whenever you like.
The issue I have is with project ownership. Forking a project is great. That's why there are 14 forks of Croniter. The issue is that when there are two divergent forks, it is not easy to tell what's going on. When a useful project gets abandoned, we typically don't have a way to deal with the consequences. Your method of forking and pulling changes only works if I am making really minor changes. However, if my changes conflict with the upstream in a major way (say I went about solving a design flaw differently than the newly awoken upstream author), I cannot proceed. Now if I want to use the upstream version I have to re-write my own software. Or I could continue with my own version, but without the benefit of upstream. Both choices are evil.
Instead, perhaps a good way to say "I officially abandon this project. Someone please inherit it." would be good. This could be done at GitHub level, where if I search for croniter I could get a suggestion for "Did you mean this fork of croniter that is significantly more active?" The issue is that then I want to install the code via PyPI, Ruby gems, etc. and the same problem arises there.
Perhaps if both hackers and users took some pains to set expectations and investigate codebases in advance (respectively), there'd be less frustration all around. I've been on both sides of this divide.
[1] Yesterday's fuzzy-autocompleter for vim is an example: https://news.ycombinator.com/item?id=5169062. I don't really consider autocomplete to be that useful (mild payoff in small codebases; being laggy 1% of the time negates all benefit), but it still seemed cool enough to be worth trying out. I was self-aware that it might lead to frustration (because it did a good job setting expectations), but to its credit the documentation was excellent.
But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot.
The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver:
c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates)
The above is an issue that's bitten many people, yet everyone continues using MySQLdb.
Right now it's much sexier to do the latter -- hey, you might have the next RubyonRails!
1. The original owner is not there to give you commit access, so you have to fork the project. This means that if the project had some number of users you cannot bring them with you. Imagine if there was a better version of Django out there, made by a group of talented hackers but you never heard about it because GitHub never told you that out of 1,500+ forks of Django one is really pretty awesome and actively developed.
2. The original owner is not there to give you access to distributing the software. This means that even if you create and maintain a fork of the original project, you now have to distribute it under a different name, once again losing popularity to the "standard" version.
Don't get me wrong, I'm not advocating that if a project is abandoned it be given to the next runner up automatically. The above issues also serve as a negative feedback loop preventing all sorts of bad software from cropping up. It just means that large projects like ImageMagick can effectively become zombies. You develop your code against them, then realize they are no good and have to re-write your code against a fork or evolution of that project.
I learned for myself a few key signs that show when a project is abandoned:
* The author never comments on or closes issues.
* Issues continue to be opened, but users begin to report bugs in more basic functionality as time goes on.
* The author has a Twitter feed or blog (or other source of life signs) which he updates. This provides a signal which shows that the author is actively focusing his efforts elsewhere. A lack of public activity is not a signal, because it leaves room for speculation. Activity elsewhere likely means the author has moved on.
All of these signs taken together indicate that a project is abandoned. Here's an example of such a project: Brian Noguchi's everyauth [1]. There are 163 issues open, and all recent ones have no trace of comments from Brian (sign 1). One of these issues is mine. The example code in the repository is broken, and one of the OAuth modules has a showstopper bug (sign 2)[2]. Brian's Github activity shows he is working on the admittedly more important derby.js project (sign 3)[3].
I am not focusing on Brian because I want to shame him, but everyauth is a good example of an abandoned project, and all of its users should pack up and move on.
[1] https://github.com/bnoguchi/everyauth
Github, while nice, isn't exactly a bug reporting tool either. It's more a "if you have a patch (whether feature request or bugfix), post it and I'll decide whether or not to integrate it." I like how it encourages people to hack on source (just clone, hack, and send a pull request!), but, much as I hate to say it, that doesn't work for everyone.
Especially in the case of JWZ. While it would be fantastic to have him contributing patches, he just doesn't have the time (and chooses not) to do that anymore. The thing about JWZ is, caustic though he may be, he's very often right, and extremely insightful, not a clueless newb. If he files a bug report on a project, it would well behoove the maintainers to take notice.
Sure, you can do a pull request instead, but most of the time people just report issues to the maintainers without providing a fix.
I agree that facebook seems a little silly to use for something like that, but if the author is young then that may be his primary (or only) contact with the world that he regulary checks.
As for web-only? That would be the way I would go, if I had to -- very little spam issue and you can put a captcha on it if it becomes a problem.
But honestly you sound like an whiny complainer in that comment -- people have given you some very useful software for free, do they also owe you a bug reporting tool of your choice?
Git-hub is awesome in that regard, because it enforces 'put-up or shut up', you have to provide a patch if you want to get the issue fixed.
The thing is, to most people who aren't geeks, Github sounds like somewhere you want to avoid, where nasty hackers meet to compare notes on their cyberstalking victims or something.
The geek community seems to have an almost comical ability to come up with such terrible names for projects and not even realise it.
(And I write that while posting on another site that sounds like somewhere nasty hackers would meet to discuss writing viruses or something.)
I think it's very telling that many of the comments in this discussion speak positively about OSS because you can fix things yourself or there's an open system for submitting patches. I wonder whether the people posting those comments have even considered that the overwhelming majority of people using big name OSS software like Firefox or LibreOffice today aren't programmers and aren't going to report bugs like a programmer.
I have seen several projects where both SF and github host files for a project, and are both kept up to date (as a way to offload the downloading of the project, I guess) but tons of unanswered questions in both projects trackers..
look at the open source project for zenoss.. they host their own bug tracker, (makes sense, its a commercial company with an open source product) but they don't put any notice about it on sourceforge or github where different files/code are located. (and the sourceforge one is full of spam).
He might be very responsive if you use this way to report bugs or he might ignore them. That page does not tell anything about it.
To see how this is done properly, check out for example:
1) Go language issues: https://code.google.com/p/go/issues/list (I had a bug fixed within 9 minutes after posting a few days ago!)
2) the PostgreSQL mailing lists (see other submission regarding "Tom Lane writes a lot of emails")
Greg at End Point thrashed this system better than I can, two years ago: http://blog.endpoint.com/2011/05/postgres-bug-tracking-help-... (TLDR: no metadata, no workflows)
For reference:
Also, it sucks when I need to sign up for something to report a bug.
Obviously, they are different things - I don't think that very good test coverage eliminates the usefulness of a bug database... but maybe it does make it easier to get away without one.
Suppose you have a discussion forum, and someone sees a potential bug. In the past, they might add a bug report. Now, they go to their integration testing suite and write "URL shortener should provide valid menu links at navigation depth greater than three" (just to come up with a completely contrived example that never happens in real life, heh). This still tracks the bug, and is probably more useful, because now you can't ignore it because there's a red bar in everyone's dev environment.
I do notice a lot more unit and integration testing these days, so it is possible that some of this is standing in for what used to be a bug database. I hope nobody interprets this as a claim that it replaces everything you get from a bug database, I'm just seeing it as something that might reduce the impact of the absence of a bug database.
"This individual doing open source software FOR FREE is not fixing bugs that I provide to him to fix FOR ME AND MY NEEDS is not fixing them to MY SCHEDULE AND SATISFACTION. THE NERVE."
Indeed. I feel for you.
If you actually read the post, jwz isn't complaining that bugs aren't being fixed on "[HIS] SCHEDULE AND SATISFACTION. THE NERVE." He doesn't say anything at all about bugs not being fixed.
His complaint is that his bug reports are being completely ignored, and/or developers providing no way to even REPORT bugs.
I imagine he would be happy (well, HAPPIER, it is jwz) if a project owner said/posted "this is a one-man show. I'm really busy and don't have any time at all to work on it right now. Here's a bugzilla/github issues/whatever where you can report bugs and at least see if it's a known issue"
Or perhaps the coder responsible for that subsystem has been on holiday and is working through a backlog. Or perhaps their 'day job' has blown up on them and they haven't had quality time to look over things.
I think jwz is just being precious here.
You can't honestly expect that John Q. Public is going to be as successful as a Chrome team member for getting a bug accepted; I've seen many of the bugs that get filed for Chrome, and I'd say a fair amount of them are by non-technical users.
I'd be willing to bet that if you took any non-trivial project and ran the same metrics on the bug DB for developers vs. QA, you might get about the same results. When a dev puts a bug in, more times than not, it's a bug. But when QA puts one in, there's a very good chance that they're either mistaken about the expected functionality, or are reporting a bug that's already been fixed in trunk.
Of course, you might argue that it's easy for us, as we don't have a ton of users opening gazillions of bugs. It is a fair point, that simply triaging bug reports can become a big time sink in larger projects. Makes me wonder if some technological tooling (eg, better "dupe" detectors, etc.) could help manage the problem.
My favourite situation is when I submit a bug with all the information I can gather and after a year (or even more) a developer updates the ticket asking if I can still reproduce the problem. Most of the time I can't because I moved on and I'm using a different software, upgraded version, or simply I don't care any more. To be honest, I almost prefer the bug is automatically closed because it won't be fixed (no activity for some time, Fedora EOL, etc). At least the bot closing tickets can't care more :)
But it's not always like that. I've been submitting bug reports for 10+ years, and sometimes you get a fix in hours or days. Your success may vary :)
I've found that very popular projects (ie. Ubuntu, Fedora, or GNOME), with a large user base are suffering of "bugtracker bankruptcy": too many tickets to be handled properly. I don't know the reason for that, but I suspect it could be related to automated bug reporting used by distributions plus the increase of "consumer users" and not "producer users". If the distributor/upstream relationship is not working (ie. distro packages version X, upstream is already working on X+1 and lacks of manpower to maintain X), then after some months you get a mail from a bot :)
</rant>
Anyway, if you think about it... that's a good way of experiencing OSS: adopt an unmaintained project!
https://wiki.mozilla.org/Bugmasters https://live.gnome.org/Bugsquad http://www.mediawiki.org/wiki/Bug_management/Triage
So adopting a little bit of a big project, and watching its bugs come in to help triage them, is going to be helpful for this increased ratio of consumer users to producer users.
You need to post to the Imagemagick forums: http://www.imagemagick.org/discourse-server/
They are extremely active and you will get a response from someone within hours.
Several of the people who frequent the IM forums are extremely experienced and helpful including:
Anthony: http://www.imagemagick.org/Usage/
You're likely to get a much better response if you make a donation.
I post my issue and ask for feedback, never see any response.
I just chalked it up to the "support is expensive so we don't do any" model. I worry that the way Google handles support is spreading to other companies faster than the way Google handles algorithms or stripped down interfaces.
Don't rant and be rude to all open source projects because you're obsessed with a few poorly run projects. Open source is in a better position than ever when it comes to developer accountability and bug fixing.
1. http://www.johnmyleswhite.com/notebook/2012/10/02/finder-bug...
Couldn't be farther from the truth. Apple's development process revolves around their bug tracker, to an extent that I haven't seen anywhere else. If it isn't in Radar, it didn't happen.
1. if people would just accept that they need to buy software, it would be easy to charge for it, and it would be easy to support it
2. "hey, it was free, ass-wipe" [1]
Either way I approve.
[1] http://www.youtube.com/watch?v=3Y8x5hbdaPM&feature=youtu...
As for the "ass-wipes can't be choosers" argument, that's just flat out unprofessional. If you were building a house for Habitat for Humanity, would you slack off and not hammer all the nails in because "hey, it was free, ass-wipe"? Maybe my point of view is skewed, because in one of the charities I volunteer for, doing something half-assed is fairly certain to get someone killed.
I get that OSS isn't always someone's day job, they may not have enough time to handle bug reports or documentation, etc, etc. But as the solutions to supporting an OSS project go, ignoring bug reports or making them hard to file rank pretty low. If someone doesn't have the time to handle the load, they need to communicate that. Post it on the project page. Put out a call for help to other volunteers. Have the bug reporting system autorespond that the project is not moving very fast. At least let your users know where they stand.
Speaking for myself, I make a personal point of pride of responding to every bug that shows up on my bug trackers. Not that it's very high traffic at all. :-)
It was several months ago and I never got any reply. That being said, the last release is from 2010, so it might be abandonware.
Anyway, if you use KeepassX to store your passwords, be careful, the whole crypto behind felt a bit amateurish.
I use KeePass2 myself. It uses a new file format, and it's .net, runs well under mono on linux. And it's definitely not abandonware.
The assumption is that a 'real' bug will eventually be reported by a 'serious' user or developer. Maybe that's wrong but that is how it works in the real world.
It would be nice to have a bug tracker, but I just don't believe it would be used to track only bugs and would thus take up time which I'd rather use for developing the software.
Basically, if you put your email address in a project, you're going to get emails from random people for the rest of your life. Sort of like getting a tattoo, a spur-of-the-moment decision early on sticks with you forever. Just one possible reason the projects you look at don't have an e-mail address for the maintainer.
Based on a small sample, Red Hat seems to do worse with "documentation bugs" - such as when their documentation described using raidtools in RHEL4, when it had been replaced by madm (which appeared to me at the time as "missing raidtools").
At first it is great fun, reducing testcases, talking to users, etc.
However, the problem is that you still aren't a developer, and can't actually fix bugs. Also, because this is open source (and you are just a QA person), you can't direct what bugs you think need fixing most importantly. Those bugs lie open for months, making you (the QA person) look bad, but you obviously can't do anything about it yourself. When you complain, the obvious suggestion is "move into development, then you can fix bugs yourself".
Of course, when you do that, you don't have time for QA any more. Therefore, good QA people usually either leave, or turn into developers.
Do I have a suggested fix for this? Not really. We can't really demand that developers donating their time do what QA people donating their time tell them to do.
I have no problem QA'ing other people's work. And, I have no problem when someone else finds bugs in my code. Maybe we need a QA-swap-meet.
On my second day I discovered that QA listed a bug as high priority with a "1", while the developers put a "10" on the highest priority. I think you can see that there was an issue. They had operated with this system for more than a year before I got there.
I switched them to a letter system, "A" being top priority, "B" is second etc on my third day.
Their world changed.
http://sublimetext.userecho.com/topic/52275-down-arrow-doesn...
I thought he was smarter than to make stupid assumptions. Is he ever going to fix this (bug)? Doesn't look like it.
Maybe the assumptions are left over from his experience with Netscape? There's no RFC I know of that requires some silly user-agent string scheme. But feel free to enlighten me.
And while your at it don't use terminal green on black for your website schema. Ouch my eyes.
I think part of it has to do with how Apple & M$ are handling the big pivot. OSX is turning to crap but iOS is booming so Apple is huge. In contrast, M$ is trying to sustain their old OS and it's not working.
I mean, seriously, how can someone get an email / FB message / whatever from jwz and not even read the damn bug report!?
This is beyond me. The guy knows what he's talking about.
Long live jwz, thanks for all you did.
(Okay, he does have a github page, but nothing is on it, so he must be a newb.)
He replied that he'd deleted the posts (fair enough), then banned me. Nice one there, jwz, banning someone for reporting accurately on information that you know is incomplete for them.
Amount of sympathy for his unanswered bug reports = 0.
I'd rather handle bug reports by active contributors preferably than some VIPs.
(and the swearing above? that's just to warm you up a bit for JWZ's caustic style ;)