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."
"However, Microsoft and other upgrades are binaries, and installable by end users."
Of course, the Microsoft equivalent of 'it's fixed in CVS' is even less useful to the end user, as the end user quite likely neither has nor will get access to the Windows source code.
The project devs are not the end packager. If you submit your bug reports to the project devs, the CVS fix is what you get. If you want a binary end-user fix, then submit your bug report to your packager who can provide you with a binary, and propagate the bugfix upstream.
There's a reason the package systems allow patch-the-pristine-sources and build functionality...
This is certainly a PC response and only slightly better than the response, if any, you would receive from proprietary software. Of course, proprietary software would have a response more akin to "It's in the next release." which is essentially what is described herein.
I think a claim that the issue has been addressed and not yet released is a bit of a grey area between the ideologies of Release Early, Release Often and a perception of great stability in software (It Just Works). It can be argued that the OP is a whiney-ass cream-puff who wants what he wants when he wants it. Just as easily it can be argued that a statement with an inferred attitude of "It's in CVS alread, quit yer bitchin!" really is just an example of what always happens when the developer community and the user community approach each other.
Users want everything now but bitch about daily installs/builds. Which means that a CVS "fix" won't do them any good in the first place since they only use the "released" versions. Meanwhile the developers are doing what they can to fix things on the time they have but would like to have a release be something that's more stable than buggy. After all, their name might be on it.
Personally, the fact that it's being addressed in CVS means that they know about it, they fixed it, and it's coming soon to a package near you. If this is unacceptable at least you have the option of pulling the CVS version ahead of the released package version. If this is all too much to handle than think of things in terms of a proprietary software product. The bug, if serious enough, will be fixed at the next major release in 6 to 12 months. That's the alternative. Open source allows you to put yourself in between these two ends of the spectrum. If you are going to call CVS a cop out, then go to the other end and keep quiet.
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.
In a company, you would be paying me money to do the work. You can bet that if you're paying me then making it work for you and fixing any bugs you find go straight to the top of my priority list. But if you aren't paying me, you don't get special priority. They go on the list, sure, but they get prioritized based on what I think is important.
I see you all the time, BTW. You're the guy who's always asking me to fix his computer. For free. Even though he didn't get it from me, won't take it to the shop he got it from, won't listen to any advice I give him let alone actually follow it, and insists he didn't do anything to break the system. It's amazing how offended such folks can be when I insist on payment in advance at standard rates.
Sounds like a job for the Sun Grid.
But seriously, for some kinds of projects, I can see the appeal to the end-user but it requires a certain level of commitment from the developer(s). On the other hand, it gives them the option to have as first response to a bug report "Try the latest build."
I think different projects are more or less appropriate for nightly builds - and this also depends on the audience. For a while I was doing my own automated nightly Mozilla builds (even though binaries were available I believe,) but I wouldn't have dreamt of doing something similar for my kernel.
Even though I have spare hardware to devote to something as gnarly as automated kernel builds without risking my day-to-day machines, I'm not enough of a gearhead to be into this for its own sake, nor file useful bug reports.
So what do you suggest? That every project must generate a "stable" release for every single patch that goes into CVS, or that every single patch must be back-ported to the "stable" branch and then generate a "stable" build?
Seriously, this whole argument is fucking bullshit. I say this as someone who has to manage a big project; a single release takes us weeks to generate and test, and this clown is whinging because I don't have the time to release more than once every two months if I'm lucky? What an ass.
I see this all the time:
"Get an account on our obscure bug database, wade through numerous options which do not relate to the program but which you are required to fill out..."
No, I do not want yet another account. Debian gets this right: anybody can report a bug via email. (though the system needs to be upgraded to not require custom email headers for certain obscure features; many modern clients like Evolution/Thunderbird/GMail won't do that)
Usually the search interface is broken too, without full body-text searching and synonym/*ed/*ing/*est handling. GNOME Bugzilla is particularly bad.
Then of course you get marked WONTFIX and NOTABUG without even a chance to discuss the problem. Again, Debian seems to do a superior job. Bugzillas are usually not worth bothering with.
End users shouldn't need to use CVS. They don't even have a formalized release anymore on the sourceforge page that is supposed to have one.
Why do they keep changing the command line options?
Why does the changelog refer to the releases when CVS is what everyone is supposed to be using?
Isn't it way past time for another formal release?
Why do they and the mplayer project have so much trouble keeping their servers working? ffmpeg CVS and the lists are down.....again. Which is not mentioned on the website.
Why did I have to search the development list for a patch that I had to apply manually, because "patch" didn't work with the patch, to get ffmpeg to create PSP compatible video after I upgraded my PSP to firmware 2.0
What's the point of having an IRC channel on freenode if there's a dozen people idling, but not really there to answer questions. If you're not at your computer, log out of IRC. No, I am not going to ask a question and idle myself for hours in the slight hope of getting an answer.
They have been working on the documentation though, thats a small blessing and with the new interest in ffmpeg thanks to the PSP and video iPod there's more traffic on the ffmpeg-user list.
"If you don't care about it, then don't release it to the public."
You know what? If you don't like the response of a developer when you ask him a favor, then simply quit using the software. You have that freedom, same as the freedom for OSS developers to even do things such as 'release and forget'. For you: the same end-result, and for the rest of us, it means a plethora of software will still be available.
--- Hindsight is 20/20, but walking backwards is not the answer.
Fine. Then check out the patched sources and start testing it.
Which is not an answer for most users. They need regular, predicable releases they can plan around.
The article is specifically about OSS developers and is just another instance of people using freely available and developed software believing that the developers owe them something. For OSS, developed as a hobby in the free time of its devs, committed to CVS is fixed unless you can show otherwise.
Some OSS developers may be hobbyists, but in terms of the most economically significant software I suspect the most are supporting themselves directly or indirectly as a result of their work. At least I beleive most people would like to. And for the ones that are supporting themselves through F/OSS, some users must be supoprting them, if not necessarily the whiniest. This is the same in closed source software too; the whiniest PITAs are usually not the ones who are paying the bills.
Speaking as a developer of over twenty years, the attitude you are taking here is not a result of the novel moral relationship of the OSS develoepr to the freeloading user. It's been a common trait of our species since we climbed out of the digital equivalent of the primordial slime. Most developers want users. In the same way that the aristocracy wants servants: they should take care of us, not the other way around. Like any good servant, they should be for practical purposes invisible; the brandy and cigars (or soda and chips) should just appear as if by magic, and they should not burden us with their problems and especially not their opinions about how we should use our time.
In your heart of hearts, you know you deserve to be taken care of, because you grace the world with your magnificent artistry. It's a scandal that the MacArthur "genius" grants have overlooked you so long.
On the other hand, most of us have learned that working for The Man sucks. The Man has the temerity to look at us as servants. Free and Open Source is attractive because we can take our blood sweat tears and inside knowledge with us if we need to ditch The Man. But being in business for ourselves isn't quite the right niche either. Every user become The Man. What's worse is they view us the same way we view them.
Which creates a new economic niche for companies dealing in OSS. They can make a living making sure all the spoiled, self-centered parties involved don't end up throwing furniture and stomping out of the room, despite the fact it's in everyone's interest they cooperate and compromise a bit. In fact, it's better that they don't end up in the same room at all.
In a sense, that's what companies with Linux distros do. They test a bunch of patches to to a variety of software, decide which ones are best and how how they are best packaged. Then they offer regular, predicatble and tested updates, rather than showering the end user with continual updates, which is in effect what the CVS tree is. Companies are also increasingly being formed around individual projects as well.
The main difference between open source and closed source companies is that for practical purposes the open source companies down own the product, even if by legal technicality they're the copyright holders. That means that users get the same benefit as the developers. If they don't like the service, the test and update policies of the company, they can walk away from the company without losing their investment in time and knowledge.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I also disagree. Users are generally not the lifeblood of an open source project.
I have never written any free program for anyone but myself. I always get paid when someone else is the target.
I have, however, given the program away for free while and after using it myself. I felt SOME obligation to them to fix bugs as the appeared, but nothing like I would feel for a paying project. I only felt that way because I genuinely like to help others.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
So what do you suggest? That every project must generate a "stable" release for every single patch that goes into CVS, or that every single patch must be back-ported to the "stable" branch and then generate a "stable" build?
Seriously, this whole argument is fucking bullshit. I say this as someone who has to manage a big project; a single release takes us weeks to generate and test, and this clown is whinging because I don't have the time to release more than once every two months if I'm lucky? What an ass.
Damn, who pissed in your cherrio's? I for one only have one problem with cvs, and its specific to sourceforge. Specifically its pure bullshit that their server for any one project is down 90% of the time. I don't mind being told that its fixed in cvs, if I could goto cvs and suck the fixed code right then and there, while the iron is hot. This bullshit of screwing around when you can think of it for anywhere up to a weeks worth of days or nights before you catch that server in the mood to actually let you get the code sucks donkey balls.
Well, actually I have 2 problems since I use an rpm based distro, and that is the comparative inability to manage a system where, because the friggin rpms won't do what needs to be done, so you garb the tarball or the cvs if you can make it work, and make away. But then yum et all have NFI whats on the system and insists that it knows better and tries to rip out everything related to printing because you've installed gutenprint due to the available rpms all being gimp-print-4.2.7, which doesn't YET support a 5 year old Epson printer. But thats an entirely separate bitch, which is only going to get fixed with each distro taking checkinstall under its wing, and making up preconfigured versions of it already customized to work with the package manager that distro uses. It can be done, I've done it for my FC2 system at home.
Now, go get a fresh bowl of cherrios, and point the accusing finger at the source of the frustration, in this case sourceforge itself.
--
Cheers, Gene
This is not uncommon. I know of a Apache project that has had books written about it, which hasn't had a release since 2003. It is still very much in active use, and there has been a major bug in it since 2003 and a fix for about as long in CVS, but no release. Fair enough if one of the dev team doesn't feel like doing something, but for active projects with several develoeprs on a major project, its important to release.
Which is exactly why you shouldn't be in any kind of support role. You aren't a problem solver, which is what a support person needs to be. Someone who likes to solve puzzles, mysteries, and who understands the intricacies of hardware and software. Think of a programmer as a writer, and software support as an editor (the human kind, who fixes up the manuscript that the writer submits).
Ideally, at least in places where I worked that succeeded, the programmers turn in code, and software support/engineering finds and fixes (or returns code to be fixed by the original programmer) the code before it goes out the door. I've been pretty good at both ends of this process, but I find the puzzle-solving and analysis to be far more interesting. That's why I make my living getting software maintenance contracts. I've seen OSS that I wouldn't have released, unless I was illustrating "how not to do it."
By the taping of my glasses, something geeky this way passes
In fact, awesome, the FFMpeg people come right out and say that if you're not using CVS to basically screw off and leave them alone.
And I confess to some sympathy for that. One of the things that stops me from releasing more of my code is that producing a nice, friendly, well-packaged distribution is a lot of work.
And honestly, that work can be pretty unrewarding. I help maintain a web-based service used by hundreds of people daily. We pay a few thousand bucks a year to keep it going, and put in a fair bit of time. We get maybe two thank you notes a month, but if it's ever down or buggy, we get a couple of complaints an hour, some of them frothingly rude.
Now, whenever I use or download something I like, I take ten minutes to write a little note to the people who make it. I encourage everybody to do that; it makes a big difference.
We get maybe two thank you notes a month, but if it's ever down or buggy, we get a couple of complaints an hour, some of them frothingly rude.
:-) But users who reopen bugs that were closed twice already (with a kind request to not reopen it again), users who complain for the lack of some features that are pretty hard to implement and think the developers should have all the time to implement it, just for them, etc etc... They get on my nerves a bit sometimes. :-)
Yes, that's indeed quite annoying sometimes, when making free (as-in free beer, mainly) software. Users still think they're like "paying customers" (at least they behave like they are), being very demanding, impatient, rude, etc.
Fortunately I hardly ever received a really rude reaction, except for some that were actually more funny than rude.
Anyway, I don't really get this "CVS cop-out" thing. What's wrong with saying "Yeah, we know about this problem, we fixed it."? It's not very clear to me from the article. It indeed doesn't mean the problem will be fixed for the user in a couple of days, but the user/reporter knows the developers are aware of the problem, and that it'll be fixed in the next release.
And if the bug is really too annoying, feel free to run CVS or backport the fix. But don't whine. You're not a paying customer, the developer has other things to do (just like you). So if the bug bothers you that much, take the time to get the fix yourself. It's already there, you don't have to write it anymore, so it's not that hard.
You say th you disagree, but then you actually agree. The OSS developer may be burned out, have a family, had a bad day. Even just that they don't care about your problem (it is, after all, YOUR problem, not theirs - they aren't losing money if you return the software).
The KDE thingy can be approached as a test project - you didn't know what valgrind was. Try it, use it. It doesn't matter if the bug gets fixed because you're learning new stuff. Finding the bug is peripheral. Alternatively, you can give over what information you can and leave it there. If the bug makes the software unsuable, find something else. If there isn't anything else, then at least there is the hope that the problem is fixed soon - you haven't lost anything).
Sure, but how can OSS claim to be better/more secure/etc than commercial software if none of the developers gives a #('$ about its users? You either have pride and fix your bugs, or you do your fun and don't claim to be better. You can't have both.
As for "but you shouldn't get surprised (or pissed off) if they don't immediately jump to do your bidding." Actually, I had 4-5 functionality bugs in mind back then. All were pre-existing. Between 1-3years old, confirmed, but either non-assigned or wontfix. Meanwhile things like skins were being worked on.
A developer who won't fix a 3yr old bug, but works on 'cool fun' stuff deserves no respect from me. It's not my rights I'm worried about. If I wrote software that had gaping bugs, I'd fix them, because I'd have pride in my work. If OSS developer's pride means slagging off commercial software and telling users to p*ss off, then thye will be no better than script kiddies who pat each other on the back and tell everyone else to #$&% off.