Slashdot Mirror
The CVS Cop-Out
NewsForge (also owned by VA) has a short piece attempting to call into focus one of the major complaints of end users, the "CVS cop-out". From the article: "One of my biggest pet peeves with open source software is what I call the CVS cop-out. It works like this: I criticize (accurately) some shortcoming of an open source application either in an article or in conversation, and someone responds with, 'That's not true! That feature was fixed in CVS four weeks ago!' [...] I bring up the CVS cop-out not because I have an answer for it, but to air it out. Sometimes, giving a problem a name helps to foster discussion that leads to resolution."
...was fixed 4 weeks ago! Didn't you get the memo?
Is this really a problem? Nathan would lend more weight to his argument and coined term "CVS Copout" had he given at least one concrete example. First, Nathan explains this "copout" isn't really a problem for big and well-supported applications and projects like Firefox (duh).
So, he cites:
So his "example" of this problem is by his own admission, made up. It would be nice to hear of a real life example when airing grievances to an international audience.
Finally, Nathan proposes it better to make available for alpha and beta testing the development branches of CVS projects. I thought in many cases that was already true. Regardless, that idea would provide relief to a tiny fraction of the population, still there isn't anything (IMO) wrong with the idea.
As for his made up example, he submits that if perhaps there were a bug that stopped Rhythmbox from playing mp4 files it could be four to 6 months before the pipeline provided relief. I doubt it. For mainstream and widely adopted and popular formats I see fixes turn around in a couple days... e.g., when gaim suddenly lost contact with Yahoo chat protocols, a new release was available the NEXT DAY.
Giving a problem a name and identifying it is the first step to solving it. Is this one?
(Speaking on behalf of open source developers everywhere)
You're right, next time we'll respond with "Screw you, if it's really that important -- fix it yourself and provide binaries to everybody on the Internet"
First they want free software.
Then they want good software.
Now they want good, free, software - instantly.
F*cking users.
And I thought this thread was about a drug store chain getting rid of their security officers......
The problem is that developers (open source or not) tend to think that "committed to CVS" == "fixed. Once it's been tested, documented and released, then it's fixed -- until then, a fix is simply in the early stages of development.
Users are the lifeblood of an open source project, and bug reports are the white blood cells. Even when there are dupes, they're a good thing.
Users are *not* necessarily the life blood of an Open Source project. Most of these projects are developed to scratch an itch of the person who wrote the software. Users typically are the people who came along for the ride thanks to the developer's good will.
When somebody doesn't like an article this guy writes, are all the duplicate e-mails bitching about it a 'good thing', or do they just drastically reduce the usability of his e-mail account while giving him more work to do when he could have been writing?
You think the 'CVS cop-out' is bad? It's the incessant demands of users that are the reason I don't even put my name on code I release as Open Source anymore. I'll fix the bug or add the feature when the lack of fix/addition is getting in my way. Until then, the code is open; add the change if you care that much about it. And if nobody uses it because I'm not bending over backwards for them, well, I could care less because I'm not out to win a popularity contest. What more do you want from a guy beyond a BSD license anyway?
The problem isn't the 'CVS cop-out', it's the 'Take Over the World Myth'. Users of Open software are under some crazy impression that most of it is written in order to take over as much market share as possible. People who write about open source are using a different definition of 'win' than people who write most open source software.
The most annoying is:
"That problem is fixed if you install Bob Smith's modified version of libsomething, that breaks several other applications and is only available from his slow, unreliable, often-unavailable personal website, then recompile our application using the three misformatted patches some yahoo posted to our mailing list across seven months back in the spring and summer of 2003. No, we don't have links to the posts, don't you know how to use the archive search?"
And of course, they have no plans to integrate any of these changes into their codebase: why should they, when the solution is so easy?
This space intentionally left blank.
Now, yes, they do have regular CVS snapshots I could try (which they actually warn against using!), but the most frustrating thing is that the last stable release - containing this crashing bug they've known about (and already fixed!) for potentially years - was in September 2003, which is *far* too long to go without rolling in CVS fixes and producing a new stable release.
If developers don't regularly release new stable versions (at least every 6-12 months), then it's discouraging to end-users to even bother reporting fixes - it gives the impression that the project is dead and you won't see a new version for years, if ever.
Well. What kind of response did you expect when response that is has been fixed in CVS is not enough?
Fixed in CVS means:
1. We agree with you criticism
2. We have _already_ done something about it.
3. You can expect the fix in the next release.
The only time such an answer is not 100% perfect is when you are just looking for things to criticize to make them look bad. Then it is very unsatisfactory that it has already been fixed.
A related and much worse problem is when the developers refuse to consider your bug report because you failed to test is against the latest CVS. "Well that's interesting but 2.7.92-pre2-test19-rr-gg-123 is over 16 minutes old. Could you please retest with ..." and that sort of thing. That is a true copout because the developers know damn well they haven't addressed the problem specifically, so there's no reason to believe that it's resolved in newer code. But it does give developers an excuse to delay addressing the problem.
Want bugs fixed faster? Quit bitching and start testing.
/.
.tar.gz or .zip of an executable. THAT they can test.
Typical I-have-no-life-but-my-project response.
Here is the typical "test" from a user perspective.
1. Website has dire warnings about stable vs unstable, so user gets stable version.
2. User finds bug and reports it. Often they provide no useful information other than "feature X doesn't work".
3. Odd are, user just e-mailed someone which means this now needs to be entered into development bugtracking system, like bugzilla. User is pointed to bugzilla and/or proper bug reporting method.
4a. If the user is worth a damn, they will attempt to report it properly.
4b. Other users bitch about FOSS software quality and leave to flame on
5. User spends days trying to figure out the proper way to report a bug via bugzilla. Here is a tip to developers -- Bugzilla is NOT USER FRIENDLY AT ALL if you are not a developer. It sucks like a Dyson. If you're a developer, KNOW WHAT YOU ARE DOING and use it daily, it is great. If not, it is a bitch.
6. User offers to test, gets development version.
7. User finds out that all the real action is in CVS/Subversion and spends the next 6 weeks trying to figure that mess out.
8. User finally gets CVS source, takes the next few days trying to understand the code.
9. By the time user understands the code enough to make a change, someone else has changed something and they have to resync. Loop to 8 at infinitum.
Moral of the story? Testers are NOT developers. If you want quality TEST people then never EVER send them to Bugzilla and never EVER give them CVS/Subversion. Give them a SIMPLE form to fill out for reporting bugs that can then be parsed by someone who knows Bugzilla or your bug reporting system.
Don't assume testers have a development toolchain. Don't expect them to use CVS or compile/link anything. Give them a
If you're moving so fast in development that this is unreasonable, then don't be asking for non-development testers.
Learning HOW to think is more important than learning WHAT to think.
It depends on a lot of circumstances.
Fixed in CVS may also mean the following:
We fixed this problem in our unstable development tree, which you can't deploy at a customer, or anywhere else. Also, we won't backport this patch to the current stable release, because we don't have time for this. So we basically leave you with your problem, until our unstable development tree at some time maybe gets released.
And this problem isn't restricted to OpenSource at all.
I'm running Dapper on test machines at work right now so that I can help find bugs. When it is released as "production", I will know that the bugs that are important to me are fixed.You would not believe how hilarious that is.
Try this approach: "I will pay you $200 (US) to backport that one patch for me."
Then see what kind of response you get. Personally, I've always found that offering to pay someone to do work that I require works unbelievably well.Again, as the end user, you really have two options in that case:
#1. Grab their code and start testing so it gets to "production" faster.
#2. Pay one of their developers to backport the patch to the last "production" version.
This is where Open Source really rocks. You (the end user) can really HELP the developers produce the code you want to use.