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?
Your check is in the mail too.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
"It's already fixed in subversion..."
Is it hard to write one of these?
"Hi [nane of guy on mailing list whose criticism makes him sound like an asshole],
Thanks for your comments about functionality XX. The development team is aware of this problem, and we committed a preliminary patch for the bug to our source-control system about a month ago. We're still working to make sure that this feature fits in with the rest of the system without any trouble, but if all goes will, you should see XX improved in our next point release.
We really appreciate user feedback -- thanks a lot for talking to the YY team!
Best,
me"
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
This isn't unique to open source. How many times has Microsoft told us to upgrade because of the enhanced security in the latest version of Windows?
This is my sig. There are many like it, but this one is mine.
do you really want a new version put out for each bugfix. maybe a few versions a day.
then you would be complaining about how many versions there are instead.
You mean it leads to retrospective resolution ? That is indeed strange !
Aside from it being a slow news day.
So its a problem, when you are talking to the developers, for them to say that it is already fixed and where you can get the fix? If this is a business concern, you should take it up with the people you are paying for support (if they exist).
"Wanting to be a parent and handhold hundreds of strangers" isn't on the list of pre-requirements for someone to be an open source developer. There quite frankly isn't physically enough *time* for that sort of thing.
Do you want hastily written software or do you want software that works?
Any non-trivial software complication is extremely complex. Fixing bugs can create new bugs. Fixing those bugs can introduce even newer bugs, ad infinitum.
By placing code in CVS, it gives the developers a way to measure their progress but also allow users to test the code.
Want bugs fixed faster? Quit bitching and start testing.
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?
Mplayer: critical bug, fixed 2006.02.15 in CVS, no fixed release available. Thanks for nothing, new mplayer team.
(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.
1) What is the article about? Cops who have problems with using CVS?
/. was a FUD site since Zonk and ScuttleMonkey joined in?
2) That is Nerd news!!! I thought
3) Subversion, anyone?
And I thought this thread was about a drug store chain getting rid of their security officers......
People don't like being criticized. If you go around and pick fights, you shouldn't expect them to drop down and kiss your --- on the the spot. find ways to demonstrate the problem without being in conflict.
Some fixes are more critical than others and has to be prioritized during a build. The good thing is that as soon as it is in the main branch of a version control system then it's in and will pop up sooner or later.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It's a way of saying that there is no need to bring a problem in front of the developers. The bug is fixed, so it doesn't need their attention anymore. Every software has release cycle problems: Users would love to get a fix for a problem right away, if they think it's an important problem. On the other hand users want to update as seldom as possible, because updates are time consuming, even the ones which you don't install. The balance is hard to keep, and with Open Source it's a little harder because users get to see what is already fixed but not yet released. Hence the relatively large number of users who regularly use beta software. "It's in the CVS" just means "if it's important to you, you can get it, but we're not going to force this update on everyone because we don't think it's that important."
It's only a cop-out if the developer/development team leaves it at "fixed in source". Given the parent's approach, it isn't a cop out, since the full scope of the solution (fixing in source and releasing, eventually) is presented.
It's normal for software users to be impatient with the time it takes to produce quality stuff. In the closed-source world, that impatience often turns to frustration as the user's requirements are ignored, or copped-out on, by the vendor, whose internal process is completely opaque. With open source, there is at least the ability to check whether the "fixed in CVS" statement is actually true. And if you really, really can't live without the fix, you, or someone you hire, can take that source patch and apply it to a local copy. You lose external support that way, but at least you can solve your immediate problem.
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
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 duo of "use the CVS" and "we don't support CVS" says "I twiddle with this code but I don't care to have anyone using it"--which is fine, but be honest about that. Or appoint someone to handle stable releases.
As already mentionned one of the alternatives is (on the extreme end) multiple daily releases that may or may not work well. The other is that it works like most commercial software where the bug fix is written, but because the release cycle doesn't have another release for 3 months you won't see it unless you manage to beg and plead so much that they give you access to it with a legal disclaimer that might as well be a book (ok, I'm exaggerating a bit, but I've been frustrated many a times talking with dev engineers at a company who said the fix I need is done, but that it won't be out for a while). Personally I'd rather have the option of grabbing a bleeding edge off CVS that has a bug fix and see how I fare with it than having to deal with constant upgrading or not getting anything for a while.
Seems to me this is easily solved by developers saying "That feature is coming, we're working on it" instead of "It's already in CVS! Stop complaining!"
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.
... make sure your budget makes it on the screen. Any effect/costume/acting/writing that isn't reflected on the screen doesn't exist in any way that matters. Similarly, and my own project was as guilty of this as anyone, anything which doesn't eventually make it into a release might as well not exist. We had some awesome functionality which just never managed to make it into the main branch, and our users would post feature requests saying "We want X! Give us X!", and we'd say "Hmm, well, we hope to get around to integrating it in the next release but in the meantime you can do the following hacking on your system to get this working" and the users would say, quite rightly, "Thats fricking voodoo, get back to work". Here's some other things OSS as a class could stand to do better (exceptions, of course, exist):
1) Install programs which are as easy to operate as the standard Windows ones. i.e. "click next until it terminates" should get you a usable program deployed in our best guess of a most useful default configuration.
2) Documentation. Any documentation, at all.
3) Documentation which isn't four releases out of date.
4) Documentation which is actually written in the end language of the user (oh that has caused some hilarity at the office, let me tell you).
5) Documentation which matches the program as released (ever been told to click the fourth option in the rightmost pane on a setup menu which just doesn't exist?)
6) More regular releases. Lots of the business world, in particular, could use a nice solid schedule to plan around, but it would be nice to tell home users "While your current version will work, if you come back every 6 weeks you'll get new goodies".
7) Simplification of the bewildering array of options for downloading packages into something end-users can wrap their heads around. Has anyone done usability testing with non-technical people to see if they understand the whole "stable/dev/nightly" thing that a lot of OSS projects use? Seems to me that could probably be simplified as "Recommended" vs "Everything else".
Help poke pirates in the eyepatch, arr.
switching to the Subversion cop-out... its more efficient and that way you could cop-out even further ..
"well I fixed that bug but it was in an atomic commit with all the other pointless bugs you have discovered and in the middle of it the power went out and I don't want to resubmit until I'm sure its safe"
The writer's probably familiar with the same thing in hardcopy publishing: a magazine prints an inaccuracy, realizes it after publication but before the magazine hits the stands, and puts a correction in for the next issue. Once the magazine hits the stands everyone in the world starts writing in about the error, and the only thing the magazine can say is "We know, we've already written the correction and it'll be in the next issue.". Their statement isn't a cop-out, it's a simple fact.
Same with the "It's been fixed in CVS.". The developers know about the bug, they know how to fix it, they have fixed it, and there's not a thing they can do further until the next release version with the fix in it goes out. Often the fix is intertwined with other changes so it's not a simple matter of applying a small patch and releasing a bugfix version, and there's always testing to make sure the fix doesn't break anything else (and fixing the breakage if it does). Plus, if they do decide to go back, remember that they're already well along the way to the next release. Coding's been done, all that work has to be interrupted, put aside, then picked up once the bugfix is out. That can cost more time than actually fixing the bug did. I deal with this all the time at work, where a bug that takes me a couple of hours to diagnose, fix and test can, when it pops up in production near the mid-point of development for the next version, cost me half a week or more of development time. Needless to say I try to avoid that kind of costly backtracking unless the bug's a true world-shaker that absolutely can't be lived with.
The "It's been fixed in CVS." can be translated roughly as "Yes, we know about it. We've fixed it. Every bit of time you make us take repeating this is time we can't work on getting the fix into your hands.".
If you're a novice user, complain to your distro. If rhythmbox couldn't play m4a files in Red Hat, they would patch it through up2date, or at least offer RPMs somewhere.
If you're an expert user, then pull it from cvs.
So someone's peeved that whatever they're complaining about is already fixed, but hasn't magically appeared on their computer? Or is it just that their whine has been found to be pointless?
In the former case, write a script to update from CVS and rebuild every night. Or every hour, if that keeps you happier.
In the latter case, here's a tissue...
Sheesh, evil *and* a jerk. -- Jade
The only real alternative is to provide untested software (such as an automated build - and that's assuming the automated nightly build actually succeeds in building).
Manual testing is required for releases because fully automated testing, including things like unit tests, are only useful to a limited extent.
Users are a lot more annoyed by untested software that is liable to crash, exhibit unexpected buggy behavior or trash their data, so it's a case of like it or lump it.
I suspect the root of the problem is that it's 'too hard' to track bugs that have been fixed or features which will be rolled out in the next release - most project's web sites fail to make that sort of information readily avalible in an easy to digest format.
Of course, at the end of the day if your not paying the piper, your don't get to call the tune.
Fast fixes are the whole point of CVS. You shouldn't get pissed off because Open Source isn't as screwed up as the stuff that M$ puts out.
If there's a real CVS (the drugstore) copout it's that I can't find the one use camcorders for all those neat Make projects you can do with them.
From TFA
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!"
This is certainly a legitimate beef - and deserves a diplomatic response. As TFA article states, saying it's in CVS isn't a useful answer to the end user.
IYou really have to have blinders on to think that a patch in the revision control system marks the end of the issue. The majority of Linux and open source users get their software in pre-compiled binaries, and not from CVS, SVN, or any of the alternatives.
Certainly it doesn't make the end of the issue. For the developers, the issue isn't resolved until the patch is rolled into a stable release and made available downstream. For the distro maintainers / binary providers, it's not resolved until the release is integrated, tested, and released to the end user community.
But certainly it is better to publicly maintain a downloadable, alpha-and-beta-testable "development" branch than it is to leave users out in the cold. Between the two alternatives, giving the mass market access to unstable code with recent fixes is surely preferable to the CVS cop-out.
I understand your point here - but the fact is that the vast majority of end users (who as you said run whatever pre-compiled binaries are included with thier distro) aren't going to have a clue how to obtain source from CVS, deal with any dependancies, and get it compiled and running. If you were a developer, would you want to deal with the deluge of questions and issues surrounding getting bleeding edge code up and running? I am, and I don't.
What justification is there for ignoring the long-standing tradition of "release early, release often?" Too many bug reports? 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.
There's a fine line here. I'm a fan of frequent and regular releases. But I'm also a fan of releasing adequately tested code to the end user. Short release cycles are an option for projects which are not too complex, have adequate staffing and/or funding, amongst other things. To borrow from your Rhythmbox example - and the example bug that prevented play of m4b files: this is, IMHO, not an example that rapid release would fix, in fact, this is more likely a case where code was release without sufficient integration testing. I don't know the details of this particular scenario, but it stands to reason that as you said, a package that has 50+ dependancies on external libraries isn't going to necessarily get upstream fixes integrated quickly. There may be other issues at play here (e.g. design issues, unstable APIs, insufficient developer resources, etc.).
In short, rapid release is a good thing, if the project can support it. Many can't.
In this case, the fix is probably not to roll forward to bleeding edge CVS, it's to roll back to a previous known good release.
There is no simple solution to this issue. As both a user and a developer, it's frustrating.
Sure, after the redundant bug reports, redundant feature requests and user-support requests, I sure do feel like spending some extra time on digging up the exact revision a bug got fixed and perhaps even write a nice lengthy mail with a patch attached.
/.)
Or perhaps not, it's time i could spend better. (Like posting on
- These characters were randomly selected.
My take on the article was the author is looking for binaries rather than a source code pull, as that is what the typical 'user' wants. For the most part, he would be right. What was missed is if you take the time to figure out how to download a nightly, you can probably figure out how to compile it as well. Most of the projects I work on do a nightly build from the code repository. In some cases, like FireFox in the early days, I would set up my local environment to snag and built a clean cut each morning.
Now, even though internally we have nightly binaries, we don't release them to our QA group. We will tag milestones which get released to QA that have a series of enhancement/bug fixes in there. If someone needs something that was fixed, but did not get put into a formal build that we sent out to the unwashed masses, it is their option to download and build something a little closer to the bleeding edge (if the project has a public source repository) or wait for the milestone that contains the feature/fix they were after. He is lucky to even get this 'roll your own' option. If he can't, he waits like everyone else. Actually, he could even pay someone (like me) to to the builds for him or spend his time learning how to sort code to binary... if it was that important. Big customers can get special builds even in our closed source stuff.
Don't see the problem, other than having yet another option open to him.
+++ UGUCAUCGUAUUUCU
But... Linux is not Windows. Seriously.
With Windows, you get fixes/upgrades when the binaries are released. With Linux, you can wait for the binaries, or, if you are comfortable with compiling, you can get fixes/upgrades slightly sooner. It's a feature, not a bug.
If you are prepared to spend some time and have some time practicing compiling from CVS (and it's not all that hard to do) then bonus! You get fixes a little early. If not, wait for the binaries, and the really cool thing? Double bonus! You still get the fixes earlier, because open source delivers fixes faster than closed source!
~~~~~ BigLig2? You mean there's another one of me?
It's called a development pipeline. Like linux stability and security? Shut your piehole. There is a QA process associated with all of that stability, and if it means that *when* there is a non-security related bug in an applications code, the fix gets tested accordingly so that it doesn't cause other bugs elsewhere, that's acceptable. Now, this assumes you are using a slow, lumbering, secure, stable linux such as Debian stable. If you want your bugs fixed instantly, choose to use CVS. You have that available to you. Tired of the lag of package compatibility testing? Use a distro that is more bleeding edge--Debian unstable, Fedora Core, etc. Change and stability are mutually exclusive. This article is lame. Sorry to rant, but you want to whine to open source developers, pay them to listen to you.
In the community the deployment pipeline often gets neglected. I know this problem myself. You keep dev'ing at the project and tend ignore end-user ready deployment. And they have to fuss about with old versions. Luckyly we're seeing a break in this trend with OSS projects getting into competetive marketing and end-user management.
We suffer more in our imagination than in reality. - Seneca
"One of my biggest pet peeves with open source software is what I call the CVS cop-out.
Well, clearly one solution is to switch to SVN...
We need to retrieve code patches that were posted to CVS three months ago. This is not a joke. We can patch the code after we get back. You must bring your own computer. Functionality not guaranteed. I have only done this once before..
...there was a simple fix for that.
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
In open-sores software, the SCM system is transparent and hence, if you were told "that will be fixed in version bar.x.y", you will say "but it's fixed in CVS! I want a release now!".
In one of the BSD's in which I do work, the release cycle is month(s) long because it takes a long time to do builds, test them, write release notes, populate the mirrors, and coordinate the announcements. Plus, you have to deal with the whining of people asking when feature 'foo' will be fixed.
My peeve is when I make note, on a project mailing list, or in their bugzilla database, that feature 'foo' is broken, and supply a way to reproduce a problem, you often get told "the source is right there. Fix it yourself". It's like "hey asshole, contribute!" whereas my response is "sorry, I'm too busy writing device drivers for another OSS project and I really just want mplayer to work so I can watch TV." IOW, I contribute, _elsewhere_.
Ignored or completely unknown.
It means someone has spent the time to make an issue known.. (ie a PROPER bug report, not a random complaint without real info on some completely random message board). The issue has been addressed and is currently fixed. CURRENTLY fixed does not mean it has been an official release but the code has been fixed or written.
It means it will be released inthe future, but if it is that big of a deal a patch can be made. Otherwise you have to play the waiting game, but atleast at minimum, the code can be snagged and patched over (how easily depends on what the issue is)
CVS allows not only for developers to share, but also end users to grab the latest (and snag the files they need to make a patch, it isnt the easiest thing in the world, but it isnt exactly brain surgery)
The phrase "more better" is acceptable English. suck it grammar Nazis
So easy, many programs and distros already use it: Keep multiple CVS branches. One of them is your development branch, with new features being patched in. The other is your stable branch, which starts with your stable release code and only receives bugfixes. The stable branch allows you to fix a bug in the release code and quickly release the fixed version, without having to roll together and debug your XYZ new features.
Documentation which is actually written in the end language of the user (oh that has caused some hilarity at the office, let me tell you).
Do you mean techspeak/jargon vs. lay language, or do you mean French vs. German?
actually i thank people for their sugestion and tell them it will be added in the next version. they are not going to read the change log anyway
It sounds like that was a project with poor/no release schedule or release engineering in place. If everybody writes code and nobody ever bothers to get a release out the door, then OF COURSE "fixed in CVS" becomes meaningless to users.
The solution here is a better documented release policy that project admins try to stick to. If you release a stable version every 6 months, and agree to fix critical security and functionality bugs on the stable release if they occur, then users know what "stable release" means. If they want new functionality or minor bugfixes, you can tell them to use a nightly build or to to wait until the next stable release.
This is the way things should and do work for a well-maintained and managed software project of any sort.
Where I work I can do so much better than that; a guy who's responsible for testing some software I wrote most part of came to me to ask me if I eventually was going to fix "bug X", to which I (truthfully) replied, "That's been fixed in CVS for about 2 weeks, AND.. I updated its status in bugzilla!".
The +5 funny part is that this was indirectly caused by an earlier incident, which I like to call the "Bugzilla Wars!" - when I finally had him convinced to write up bug reports in bugzilla rather than hand over "bug report papers" written in Open Office, he submitted around 50 bugs in one day. However, I had to do some bulk status reassignments when I learned that most of the reports was set to "very high priority" which left little room for prioritizing anything up. As a result he recieved probably ~200 bugzilla mails in a timespan of 10 minutes. Later I recieved a bunch of bugzilla mails because he had up-prioritized bugs again with comments like "this doesn't work, and that's unacceptable!". This practise went forth and back a few times. At some point the torrent of mails stopped though, and I didn't know why...
So.. about that "bug X" I had told him that he was supposed to get a mail from bugzilla stating that the bug had been resolved, and he told me that he hadn't got any! So when we sat down to fix that particular problem, we came across a filter in his thunderbird that redirected all bugzilla mail to trash :-D
They could even do that and it would be OK. Who ever said the development team is obligated to compile to your favorite architecture and distribution? More often than not they do but it does not matter if the code is free. Your distribution can and will pick up the changes soon enough, and that's the way the vast majority of users should get the vast majority of their software.
I'd like to hear of a situation where leaving it in source was not actually good enough. The only one I can think of would be where the user has upgraded a production system. They did this to get a new feature that might be nice but discovered a few bugs that were costing them money. The solution is to test and fix the bugs before moving the production system. I'd love to hear the story if anyone has one.
Friends don't help friends install M$ junk.
What was missed is if you take the time to figure out how to download a nightly, you can probably figure out how to compile it as well.
Unless it requires a compiler that costs $1,000 for one seat (unless you're affiliated with an accredited university) and takes over 1,000 MB of your hard drive. Last time I checked, too many open source projects that run on the Microsoft Windows operating system require Microsoft Visual Studio in order to compile on Windows and cannot be compiled with MinGW, the most popular lightweight port of GCC to Windows.
my computer is there to help me get my job done
If your time is money, then you're free to pay a packager to do this compilation for you.
U send send me more of ur CVS plz. Thx.
> any of you so geeky you misread guitar as some graphical front end for tar?
Your signature contains a bug -- real geeks avoid GUIs like the plague.
I assume you have already checked in a patch and will release it shortly.
Remember that what's inside of you doesn't matter because nobody can see it.
Remember people 99% of the open source products we use are produced by volunteers with similar interests.
These volunteers have lives. i.e.: spouses, children, other hobbies, sports that their involved in, bills to pay, and possibly, maybe JOBS!!
if a member of the development team on an open source software team doesn't release to your expectations, just maybe he's busy with other things, like life!
The benefit to open source software is that it is free, and that you have the source. The drawback is that you don't get the service and repsonse that you would expect if you were paying $25,000/yr in support.
So, if there is a problem that you have with an open source package you have the options of a) fixing it yourself (please try to submit a patch back and contribute to the community. b) hiring/bribing/begging somebody else to do the same, or c) politely submitting your request and waiting for a response, and then a release.
If you're not willing to do the above, the please call microsoft at 1-800-BIG-BUCK$
Just my 0.02 cents worth.
The fact that the typical user will still be experiencing the problem is mostly irrelevant. While - accepting the stipulation in the article as I have no better data - most use the software included in their distribution, they have every ability to grab the brand-spanking-new CVS release, and those who are sufficiently troubled by the issue WILL. The bulk that don't care, well... don't care.
That said, it is unreasonable to expect journalists to be experienced with the very latest from CVS. If something was fixed 4 weeks ago in CVS, it likely wasn't fixed when the journalist started looking at the product - there's time spent using the product, time spent writing, and time between submission of the piece and publication. The fact that they will likely be using the most prevelant versions rather than the newest only adds to the latency. It may, however, be reasonable to expect one to look over the changelogs between the version they were using and the latest, and make some mention of relavent changes.
You mean projects like Windows? XP to Vista has taken five years already.
Oh yeah, there have been "bug fixes" since then and recently M$ even started making them easier to get than calling a support line and being told to browse though numbered indexes of binary crap. Yes indeed, M$ support has almost come up to free software standards with that annoying little yellow pop-up that tells you about "critical updates". Woot. There you can get the distilled goodness of all of the few programmers M$ can afford to hire. Free software comes out cleaner than commercial code and stays that way because anyone can fix the problem.
The non free way of making code broke down a long time ago.
Your distribution makes things easy, so get off the developer's back. Using your distribution's binaries is the easiest way to get go and an all free system is much easier to keep up than one with non free binaries. The less free you get, the harder things are to work with. When something does not work for me in the free software world, and that's rare, there's always another project that does it.
Friends don't help friends install M$ junk.
Hey, while i'm ranting..
.. now they think we've got nothing better to do but sit around and implement features for them. (Since they have no bugs, they don't care that anybody else does).
REMEMBER: YOU CAN'T MAKE THE DAMN USERS HAPPY.
I do work for a commercial software company, which offers our service as an ASP platform. It's cheap (almost Free - but we have to eat) and we employ agile/xp programming to do daily, or sometimes even hourly builds as bugs are reported and things are fixed, or features are added. We have been in business for 6 years, the platform is almost 2 million lines of code, we interface with systems that change continually, so new stuff is always coming out and changing.
ANYWAY - MY POINT IS: DAILY BUILDS JUST SPOIL THE USERS EVEN MORE.
Not only do they get it FREE, GOOD AND INSTANTLY
First it makes the damn user assume that everything can be done in some arbitrary unit of time, something reasonable, for most people it's around 6 hours.
It doesn't matter what it is, fix a bug, convert 3rd party library from Perl to VB.net, write a new device driver for a buggy USB device -- according to the user it should take about 6 hours, although it could take less if we had more people working on it. (Which we would, *IF* it was our top priority)
Thank you sir, may I have another???
Anyway, since everything should take about 6 hours, they put in 2-4 requests per day, so that way they don't overwhelm us, you know, but just enough to remind us exactly how brilliant they actually are.
I especially love when they remind me that if only wanted to learn how to program, they would clearly dwarf our intellect and we would all worship them because they are so smart and know so much more about topic xyz.
Of course they're too dumb to realize that they're filing bug reports for what are clearly feature/ehancement requests and of course they piss and moan when I tell them that:
1. It's not a bug -- just because it doesn't work they way you think it should. Your too smart, try thinking differently, more like a dumb person.
If you can't do that, try banging your head against the desk till your semi-conscious, and try again, let me know when you've finished and if that fixes the problem.
2. Contrary to popular belief, we do have other customers, you are not the only one, and most of the others are smarter than you and have better ideas for features than you do.
3. Why don't you try actually using the software for what it does, instead of crying about what it doesn't do. I wish I had software that did something useful like perform a blowjob, or bake me a pannini. Why don't you try doing something useful?
4. No matter how much you whine, I can't re-architect the Internet. If you don't like how this Internet works, find another one.
5. Asking to speak to my manager/supervisor about my attitude does not get your feature implemented faster, it just pisses me off. Sorry boss -- I gotta go fix a real nasty data corruption bug. Hey let me check your account, what was your username again? Clickty Click.
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.
There's no pleasing you people is there?
Perfect is the enemy of done.
Users are the lifeblood of an open source project
Let's see, how can I put this nicely? Oh, yes, I know:
Bullshit!
Lifeblood is that essential element which nourishes and sustains all parts of an organism. Users do not do that for open source projects. Having been involved in a few projects myself, I can tell you what the *real* lifeblood of a project is: developer interest. As long as there is a community (which may be a single person) of developers interested in a project, and willing to donate their time and energy to it, the project grows and develops. As soon as that interest disappears, the project stops. Period.
User's aren't completely irrelevant, of course. The fact that users exist provides some (weak) incentive for developers to keep going and their feature requests and bug reports can provide a nice stream of ideas that catch the developers' interest. And a large userbase provides a large supply of potential developers who may cross the line from just using to lending a hand. OTOH, a large userbase also provides a large supply of potential obnoxious whiners who tend to piss off the developers to the point they find something different to do, so it's not all positive.
Pure users are by far the least important part of the community, from the perspective of moving the project forward, because -- gosh this is complex, difficult stuff to understand -- they *don't* move the project forward!
I know users are often annoyed by the realization that they're powerless unless they choose to invest their own time, effort and brain cells. That's understandable, really, no one *enjoys* being an irrelevant leech (no matter how kindly viewed), and we're accustomed to the commercial world where by giving money in exchange for stuff we put ourselves in a position of (some) control.
That's not how it works with F/LOSS, though. Pure users are utterly powerless and have no real standing in the community, because they have contributed nothing. Those who regularly contribute good, detailed, reproducible bug reports are adding value, and they have some standing and generally get good support from the developers. Those who offer to pay the developers money generally get outstanding support, though that doesn't happen very often. Those who put in lots of their own time to improve the software also get lots of support.
But those who give nothing, but only whine about their pet issue, generally also *get* nothing. I understand they don't like that, but, really, what else can they possibly expect?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
This is really common, and really annoying. I probably can't compile the latest source. There probably isn't a snapshot, so I have to do the whole CVS checkout nonsense. If I do install the new code, I might make things worse because the latest code is not well tested.
The GIMP team loves this excuse.
(resizing the window causes the application to exit immediately - a pretty major flaw for a stable release)
To clarify, this program is a text based, not a GUI program. I'm not excusing the bug, nor the fact the developers have basically abandoned this project (no release since 2003), but keeping in mind that this is a CLI program, I think the severity of this bug can be lowered one notch.
To me, the problem appears to be that the person doing the whining wants more something for nothing.
The only resolution that occurs to me is for the whiner to adjust expectations...
that provide nice cheap geek toys. is there a website somewhere with a collection of such things, off the top of my head I can only think of that $10 digi cam that you took into a store to get your photos "developed" and also the i-opener. Wasn't someone threatened with legal mess over the digicam thing? I wonder what transpires after playing with this video camera.
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.
I REALLY have more important things to fret about than this - for example:
Why do supermarkets keep relocating the stock in different parts of the store?
Why is the first biscuit in a pack always broken - and in which case why don't the manufacturers just leave it out?
Why when I see "New Improved" on a product do I just *know* it will be worse than the previous one?
Why when a compiler *knows* there is a semicolon missing from the end of line 67 doesn't it just damn well add one?
Parma ham is hung and slowly matured unpacked for months in dry caves in Italian mountains, yet when you buy it from the deli it says on the pack 'eat within three days' - WTF?
L3K
PS: Just before you actually give any answers to any of these - think about it - you will just look very very sad!
AT&ROFLMAO
Broken as designed. If you want something installed with reasonable defaults, a package manager is a good way of doing that. Next-next-next implies that:
1.) No package management / version tracking. At best, the program will update itself, meaning lots of duplicated update code, and the user can't just tell the entire system to update.
2.) Not enough reading. The fact that so much of installing a Windows program is completely meaningless -- and so many error dialogs are meaningless -- you're reflexively clicking next and possibly doing something really bad. Also means we have to design our programs with the assumption that users aren't reading our messages, and sometimes, there just isn't a sane default -- and who knows if the user is going to hit what you intended to be a default?
3.) Uninstallation may or may not be possible -- how does the user know?
4.) You can use any license you want -- this is BAD. At least with a package manager, the user knows most licenses allowed in the repository are safe, or reviewed by someone else.
5.) Implies that you're downloading from somewhere random, meaning a good possibility of spyware or worse.
The OS itself generally installs with next-next-next simplicity. Programs are even simpler -- apt-get install, or a Synaptic-like GUI.
No, what we need is not a way to get random programs from random places with next-next-next simplicity. What we need is a way to get all programs into a repository, without driving distro maintainers insane.
Don't thank God, thank a doctor!
Chronic Leukemia, anyone?
- "The fix is in CVS".
- emerge underpants
- Run version with fix in it
- Steal underpants
- Enjoy!
Me personally, I don't set my votes to zero on a bugzilla bug until the fix is in Debian stable. But that's my choice. And it's important to at least mentally separate various roles in this ecosystem: developer, tester, packager, distributor, product vendor, support vendor, and end-user.A cop out? Give me a break... If it was software you payed for, then a response like that could be considered a cop out. With open source software you should be happy that they are already aware of the problem and working on it, or in this case, have already worked on it. This article is ridiculous, I mean if they start rushing out and releasing software overly quickly, then the same users would be complaining of bugs.
I mean nobody is happy when they realize the piece of software they are using doesn't do what they want it to, but to call it a 'cop-out' that the developers tell you that the problem is fixed and you have to be patient till a release comes out, is just being a spoiled biyatch. The author of the article says that most people use the version of software that comes with their distro anyway, so obviously they would have to wait for the patched version to become available. Those same people wouldn't be helped with an early release binary posted on the devs site. Here's a solution for the writer of the article if he has no patience, take the bull by the horns and learn to code, otherwise be happy you got a response at all, then sit back and wait, and most of all STFU!
My projects may well go for months with no releases. But that's because there isn't much change going on at times. I do try to make sure no one change languishes for more than 6 months. But that's for changes I find for myself. When there are bugs reported to me by users, I consider those a higher priority and try to cut a release as soon as I can verify the fix probably didn't break other stuff (and if it does, I can either tell people to stay behind by one release, or I can back the change out and re-release). And this is even though my projects are of the "scratch my own itch" type.
I do have a couple advantages over other projects: I do all the development myself, and I don't use CVS.
now we need to go OSS in diesel cars
One of my biggest pet peeves with open source software is what I call the 'I'm smackable' problem. It works like this: I criticize (constantly) some shortcoming of an open source application either in an article or in conversation, and someone responds with, 'That's not true!' and then proceeds to smack me to death with my own sizeable sense of ingratitude [...] I bring up the 'I'm smackable' problem 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.
There are many compiler and IDE bugs in Visual Studio 8 that are causing problems for all the developers that had to switch for various reasons. These bugs are well-known on the Visual Studio 8 forums. Microsoft has labeled the bugs as "fixed".
However, they refuse to release a fix for another 5 months - SP1 in October. Unlike Open Source, you can't even compile the fix yourself, unless you're very good with a hex editor and IDA.
For anyone in this particular situation, download the beta Vista WDK (Windows Driver Kit). It comes with the latest cl.exe built from their source control. This solves a lot of the compiler bugs. It won't solve the even more IDE bugs in VS8, however.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Yes, and just as often it triggers an avalance of shit - like the word AJAX did, for instance.
A developer may have fixed something but whoever is managing the distribution may not have incorporated his changes. It may be a matter of politics, laziness, and whim. When a developer says "but my fix was committed 6 weeks ago" what he's really saying is "why the hell haven't you guys fixed the distro yet"?
As for the usefulness of bug reporting known bugs -- that is why some bug reporting tools let you vote on the importance of a bug.
I switched from CVS to SubVersion and I'm satisfied with that move. It wasn't even problematic...
Pixel image editor - http://www.kanzelsberger.com
I guess I don't understand how this is a cop out. Please note that this isn't only an open source thing. Working as a software developer, I very often see situations where someone on the QA team or some manager or whatever complains about XYZ and is told "it is fixed in the source", when.. well, it IS fixed in the source, but the internal release process is such that a new full build won't be available until the next day (at a good shop, maybe longer at some place that doesn't do daily builds).
"It is fixed in the source/CVS" conveys the proper amount of information -- yes, the bug is fixed, but unfortunately you will not see the fix until the next release, unless you want to build it yourself.
Seriously, if you aren't happy for the support you're getting, I'm sure there are a lot of people who would be willing to help you with whatever problem you're having, for a fee. Heck, go to a meeting of your local LUG, or any other advocacy group, and you might even get help without paying anything!
You are not entitled to be catered to. Grow up.
http://outcampaign.org/
"That feature was fixed in CVS four weeks ago!"
Developers have failed the release early release often test.
They should be polite about it or put out a release.
At a bare minimum they should have nightly tarballs.
Obviously didn't RTFA, didn't even RTFP.
Though obviously a lot of projects have nightly builds (I remember -- because it's not that long ago -- when Mozilla's crashiness or stability seemed to require grabbing that very day's build quite a lot), I like the way videolan's done that (with a "nightlies" subdomain) and wish this convention was more widespread. (Just like, for certain projects at least, it's nice that there's a "planet.$PROJECTNAME.org" to collect various blog feeds.)
timothy
p.s. "Nightlies" would also be a good name for a line of lingerie.
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
I have been watching this... Some obversations: 1) Change does not happen in a vacuum 2) Any problem that a user experiences may or may not be due to an unexpected use of the application 3) Some problems should be forseen, ie: If you have a from and to box, and there is data in the from box, to == end of file, not "application error" 4) All usability testing is important. We used to test any program using inexperienced users (video/audio) with a simulated help desk (also video/audio). No user had prior experience with the software, only the problem *WE* were supposed to solve. 5) True software change management takes time. First, you have to make sure the new release works as well as the current release. Second, you make sure that you have not changed any functionality. Third, do the new features/fixes work the way you thought they would. This is assuming that this has passed the "smell test" (Did I make this change in order to say "New and Improved?" I have seen many programs that move "File - Preferences - Add Account" to "Options - Add Account" with no increase in functionality (with another short key combination). There was no net gain. I pull CVS updates when necessary to fix *MY* problem (and test them). Otherwise, unless I pay the developer, I work with *THEIR* schedule. This is as it should be
And ye shall know the truth, and the truth shall make you free.
John 8:32(King James Version)
nobody ever bothers to get a release out the door
.rpm (or .deb, or whatever) for the enjoyment of other users like him/her. The package could be given a suffix like "-cvs20060520", so that if somebody needs to file a bug report, it's easy to determine which CVS version that bug report applies to.
The opposite of "nobody bothers to get a release out of the door" is "somebody bothers to get a release out of the door", it's not "the project maintainer bothers to get a release out of the door". I don't see what's stopping a user, *any* user, from downloading a nightly snapshot, compiling, and publishing on his web page a nice
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.
It seems to me that there are two differing views of OSS. When a developer says "they fix bugs and add requested features because they want their software to be useful" a user agrees, then complains when bugs aren't fixed or features added, and then in turn the developers complain about the complaints--because open source developers and users aren't even talking the same language.
When developers say "I want the software to be useful" what they are really saying is "I want this to be useful to me." It's not a "screw-the-user" attitude (although sometimes it comes across that way) because a large number of the developers working on OSS projects just don't care about anyone else's problems. I don't mean that in a bad way--they aren't obligated to care, because they're (mostly) doing the work for themselves.
Unfortunately, this isn't always made clear to users. Sometime projects are talked-up by developers on the basis of what they do and users think "Hey, that's cool, I'd like to try it out" without hearing (or thinking about) the fact that what they are really doing is using something that wasn't designed for them to use. Linux is like this (or used to be) where developers were saying "This OS is great. The software for it rocks" and then end users tried it out and started complaining "Hey, it won't play my MP3s" or "Hey, I don't want to edit image files from the command line." In some cases, these features (MP3s and image editing) were implemented by other developers who cared. But it doesn't seem to me that there are many developers who really care about "users" in the sense of "Joe sixpack"
That's not wrong. It just leads to misunderstandings, because developers are thinking "I like how this works and any end users are other developers like me" and end users are thinking "This doesn't work how I expected, and the developers have the same expectations as I do"
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
Stop whining.. what you're saying is:
Oh dear, this software is totally free but not being professionally distributed.
There's nothing wrong with expecting users to get the very latest development version of software from cvs. It's not exactly hard to type a cvs get command uness you're scared of a command line because you only know how to drive a muose. In which case, what are you doing with Linux anyway?
My advice to you: Downgrade back to Windows.
You won't even be able to get a few-days old version of anything from Microsoft, especially for free, but at least you won't have those nasty command lines.
If somebody can't run "./configure --prefix=/wherever && make && make install" or "make && ./install --prefix=/somewhere" then they must be using Windows or have a broken compiler.
Said the asshole twat of a developer that has no chance of ever having a life, let alone a clue. The only thing you left out was the obligatory; 'RTFM You effing n00b!' flame. But, I suppose that you require them to join the mailing list in order for them to gain access to that helpful answer.
Your attitude is the epitome of the problem's root cause. Thanks for illustrating the problem for us all.
Or Ubuntu if you prefer.
I can't imagine ever going back to a distro where you need to wait for the next distro release to get bug fixes, I just "apt-get update" once a week.
Quidquid Latine dictum sit, altum videtur (anything said in Latin sounds important)
Stop wasting time on the Internet and go mow your lawn, now - and do it properly this time. I demand your lawn is kept to my exacting standards. and I demand it is done in a timely fashion, as defined by me, since I plan on spending my weekend relaxing on your lawn, therefore you must accomodate me.
Don't give me any bull about mowing it later because you're busy either, I'm sick of The Busy Cop-Out getting in the way of my enjoyment of your lawn.
Meanwhile... more people are downloading the buggy version, many people are bitching about how such and such features don't work and they are a piece of crap (which considering I wrote those features was very disheartening). A whole freakin' *YEAR* later, the new version is finally released, but in that time the features which I had contributed had lost all credibility because it remained unfixed for so long.
Suffice to say the whole incident pissed me off considerably and I was most glad when the admin changed hands... (which is what resulted in my fixes actually getting released). Nevertheless, the damage was done.
"Fixed in CVS" is all I could ever tell people who asked. It wasn' what people wanted to hear, but it was the truth, and there was nothing more I could do about it.
File under 'M' for 'Manic ranting'
There we go - problem solved.
The main problem I see with OSS is that the paradigm presumes that all users of OSS are also software developers. This may be true for users of glib, for instance, but is it really true for users of OpenOffice, or even KDE? The only way I see for OSS to really take off is for a break between open source software development and open source software support. Combining the two the way it's been done doesn't seem to be working all that well. They really are two orthogonal tasks, and the skill sets required really don't overlap much.
By the taping of my glasses, something geeky this way passes
Most open source developers are very happy to have people use their software for free. What very few are willing to do is provide support for free. Support isn't fun, takes a lot of time and is generally just as frustrating as coding but gives the developer very little to show at the end of the day. The price for some support is money, many open developers make some cash that way. But for most hobbiests, the price is politeness, patience and possibly even a little gratitude. Giving away software is a fun thing to do, getting pushed around by an obnoxious user in a developer channel/list is something completely different, there is no reason to claim someone shouldn't do the former simply because they cannot tollerate the latter.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
i just want to say thanks for the all the hard work you open source guys/gals put in. i don't code open source just yet, but likely will in the future, however, i do try to be generous in helping others learn the about open source programs and programming languages.
i do some programming, though, and i know it isn't simple stuff - especially when the apps get big.
i'm where i am through the generousity of others and i try to help others make the trip a little bit easier than i did.
this doesn't get said often enough. it is easy to find a marginal point to b* about, but to not say "thank you!" for the other 98% of sweetness is to be an ungrateful turd of a human being.
the proper way to address this is...
"hey gys/gals, thanks for all the great software and all your efforts. however, i was wondering if there is anything *we* (user and develope) can do to keep certain things from staying in cvs for what seems like an inordinate amount of time to end users... or at least keeping the user base better informaed so they can act accordingly. if the issue is real important, where can we send the checks to get bumped up the priority list?
again, thanks for all the great software."
many hours where spent so that users can have an app to use... and the purpose of which wasn't to create another avenue for ungrateful people to b*.
no, *really*.
there will always be room to improve... and there will always be room for common courtesy.
Lets examine the situation you describe, when a programmer writes code to solve his own problem.
Assuming he writes the program in order to use it, there actually is a user, namely the programmer himself.
And since the one user is actually writing all the code, I think it is very apt to describe him as the life blood of that ptoject.
In a bigger project, things are different, but I find it real hard to imagine the usefulness of any programming project that does not have any users...
"Users are a lot more annoyed by untested software that is liable to crash, exhibit unexpected buggy behavior or trash their data"
I'm perfectly happy with my Windows box!
I have always thought that 'security' was a retarded reason for not shipping with a compiler. Any semi-intelligent 'bad guy' will have his own box capable of compiling programs, and he will upload his compiled programs, or he could upload a compiler and C library with innocuous names, such as 'report.doc'. Even if the target system is different from the bad guy's system (ex: the bad guy only has x86 boxes and the target is running Debian PPC), the bad guy could still compile his programs using a cross-compiler.
Although I usually disagree with sacrificing security for convenience, I think it is OK in this instance.
---- "XML is like violence. If it doesn't fix the problem, you aren't using enough."
There's a difference between a release and a nightly snapshot. A release has had features frozen for a while, so it's much more bug-free than a snapshot.
There's a lot to stop any user from making a release. Doing a release requires cooperation from lots of people to do the testing and fix the bugs. Only the project maintainers are usually in a position to do this. Not doing it means they aren't doing a very good job. If it's not something that interests them, they should recruit a release manager.
A large part of the problem I think is developers who try to bite off to big a chunk for releases. One or two new features is plenty for a new release. You don't have to add a dozen features at a time and it's probably not a good idea for software security to do so. Bug fixes should cause a minor point release as soon as your sure it works. A new feature that's stable should cause a major point release. No waiting around for dozens of new features and no messing around with two dozen half assed features rather than finishing one.
And yes, I'm guilty of this too but I've learned to do better. Most of the time I take my own advice.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
There are comments bandied around these parts about being "locked into MS" if you use their software.
Reading your comments above, it sounds like by going with OSS you are locking yourself into needing your OWN development department if you want to rely on the software, have bug fixes implemented and want any general help/feedback with a OSS product you using. Is that really the attitude you want to portray? Why do that when you can just pay the license fee.
Note: I develop for MS software, I have no moral problems with MS, and generally enjoy the experience. But that doesn't really affect my question. As I have worked on OSS projects and have a great deal of admiration for the developers of those projects.
I am just intrigued by your response, because it sure seems like a selling point AGAINST OSS.
Umm, just get the version from HEAD and you'll probably get some other fixes too.
My other car is first.
With Squirrelmail they claimed it was fixed in CVS for over a year but no subsequent release or CVS version worked with PHP5. I've moved to RoundCube now and once I hacked it around a bit (to hide incomplete features) it's been great. Also it doesn't look like HTML 3.2, as Squirrelmail does.
Sweet Scheme reference in your sig!
What are you doing now, you lazy drunken obscene unsayable son of an unnameable gipsy obscenity?
Everyone should use SVN.
It's OK Bender, there's no such thing as 2.
Anyway, because I didn't have the time to spare the compile alpha releases anymore, I decided to move from Linux to OS X, and have a stable platform to work on, and have other people figure out the compiling and software upgrades for me.
There are 10 kinds of people in the world - those that know binary, and those that don't.
Recently?
Yeah, you're not at all biased. Windows Update was introduced with Windows 98, released June 25, 1998.
So, one month off of EIGHT YEARS is a "recent" addition? Whatever.
Indexes of binary... what? what the hell does that mean?
Yes indeed, M$ support has almost come up to free software standards with that annoying little yellow pop-up that tells you about "critical updates". Woot.
That "annoying little yellow pop-up" has been copied by all the Linux distros. I guess it's not such a bad idea, or annoying for that matter. "Woot", indeed.
There you can get the distilled goodness of all of the few programmers M$ can afford to hire
ROTFLMAO! Get some help my man. That reality distorsion field of yours is on too tight.
One of the problems with reviewing OSS is that so many people interpret "Application X doen't do Y properly" to mean "... and the developers should fix this for free". The CVS Copout seems to be just an extenstion of this. If the developer works for free and and has even already fixed the bug in CVS this means that the developers are great guys, it does not mean that the project is already perfect in every way and nobody should warn users that it may not yet satisfy their needs.
The author is putting up a variant of the Straw Man argument. He first defines the "CV Cop-Out" as something everyone agrees would be a bad thing but the thing is what he describes isn't really indicative of the actual situation.
He says:
"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!"
He continues:
"You really have to have blinders on to think that a patch in the revision control system marks the end of the issue. The majority of Linux and open source users get their software in pre-compiled binaries, and not from CVS, SVN, or any of the alternatives."
This leaves me imagining that the bug fix is not already released. He further makes the assumption that most people don't keep their Linux box up to date with the most recent versions of software.
"...I am willing to bet that the majority of Linux users consistently run the version of each app that is supplied by their distro."
I don't know about you Mr. Willis but my version of Linux (Susie 10.0) automatically detects and installs upgrades to the packages on my computer. I don't know for sure but I think most versions of Linux comes with something similar. I think you Mr. Willis have made bad assumptions. I believe that most Linux users do get their updates regularly. I'm not sure how long it takes for various Open Source groups to release bug fixes on the average but I believe that it's a lot faster than most proprietary software vendors. So when you bring up an old bug, it really isn't relevant to the vast majority of Linux users.
The race isn't always to the swift... but that's the way to bet!
Even if you don't get support for free, getting the software for free may be still be worth a lot to many users. The few users who just whine and doesn't contribute are not what an open source project needs.
Perhaps someone with your problem should elaborate further (like you just did in this post, about how you've fixed the problem, but you don't control the release process) instead of just saying 'Fixed in CVS'. And perhaps reroute each and every complaint or person complaining to the person that does control the release. Let them get the grief instead of you.
"You haven't paid a thing for it; what do we owe you?" seems to be the cry of those developers who are faced with the fact that users don't like their project. You're right, you don't owe anything to users. But you know that you program for them. If you programmed for yourself, you wouldn't bother with configure files and auto-detection or any of that crap - it would just work on your computer. When users like your product, you love it, but as soon as they start complaining, "You get what you pay for!" Kind of reminds me of the Simpsons: "They've given you hours of entertainment for free...what else do they owe you?" But the fact is they make the show for the viewers, and when the viewers demand that their product be good or they stop using it, all of a sudden it's like you didn't even expect people to be partaking in your creation.
::downloads CVS::
It comes down to this: you don't have to support users. Fuck 'em. But guess what, fuck you if you complain about some talking head saying how your product isn't ready for the big time. They're actually helping you - why don't you accept their criticism.
The major problem with CVS is this:
"I have a bug"
"That bug is fixed in CVS"
"This CVS doesn't compile!"
"Sorry, we don't offer any guarantees with CVS"
Yes, the developers can't do anything if they've fixed the bug already. But it's frustrating to users, and unless you wanna say "fuck the users," the solution is obvious: fix the development process so "CVS" works - increase the speed at which users can use software. That's the major point the guy is making - software development is too slow. And I don't think it necessarily has to be fixed by increase developer man-hours. I think that too little thought is spent on preparing software for deployment, and that if a project put more of its focus on that, it would be more successful.
Here's one idea that might help: why the hell are people still using make and its evil cousins automake and autoconf?? You need serious gurus just to wade through all that muck. Everyone should check out SCons, because it makes life about a million times easier.
Did you ever notice that *nix doesn't even cover Linux?
As an admin of a sourceforge.net project that started making frequent releases and then submerged in a long "CVS flux" (to use the term somebody coined above) recently, I offer the following insight plus a proposed solution.
Why we don't release? It's because that first of all, all the users that give feedback are already hooked on the CVS. The download count is around a 1000, downloads range from 0-10 a day (avg. around 3-4), but we don't get much feedback from release downloads.
Additionally, the project is currently experiencing a torrent of large changes (new features) coupled with incoming fixes for old issues. To make a decent release we would need to create a release branch while keeping the work on the "dev" branch, and then eventually merge, like the Mozilla guys do, but this is extra work and we have what, 9-10 registered developers, most active ones are more like 3 or 4, all very busy and we can't afford that.
But, anyway, the point is that the main branch in CVS is 90% of the time a snapshot that is usable, what happens is that the CVS users check it out and test it, if it's broken they send bugs or (better) look into the code and suggest fixes or even fix them or even add temporary workarounds on their app code and let us know what they've done or experienced, in detail, on the mailing lists. Of course, the "release downloader" user won't get nearly as involved. He will just walk away on the first problem and look for another C++ library.
But anyway, my point is that what is happening here is that only users involved in the project are able to patch themselves a current "release" of sorts which is not a "quality release" ready for neato zip file / doc / publish but is useable. It could be packaged and put on the sf.net download page but then the casual 30-second attention span user would probably try it, have problems and dismiss the project altogether and spread a bad word. So its better, PR-wise, to let the project look somewhat stalled with activity on the backburner than let the project look already derailed making shitty "releases" (even if you tag them "BETA", it doesn't matter, "beta" doesn't mean anything anymore).
So finally my idea is this: a FOSS projects that is experiencing this kind of CVS flux needs contribution from "fan devs" of the project. They are not *official* devs because for PR or user perception reasons they must be as separated as possible. They act as a bridge between the casual 30-second attention-span ZIP/TAR release downloader and the actual devs. They take CVS code like once every 3 to 5 weeks, do some patching to get it working on their apps, and then release it on THEIR home page, with some substantial release notes stating what works and what doesn't work. Probably the release will need its own publicly-accessible forum so people can discuss bugs, issues and stuff.
They'd take the fire for us, but at least they wouldn't be affected since they are users not the official devs. If a project has a large user base, there could even be competing "fan" releases with different focuses.
I am aware that this practice is not entirely new but it is not common practice and is currently viewed as a weakness of the project or sign that the project is dying on the hands of the official dev group, instead of a beneficial symbiotic relationship.
Sorry for the AC but I don't want to advertise my project even indirectly, I'm sure you understand.
o) Runs periodically (called from cron?)
o) Pulls latest source from CVS/SVN
o) Builds it (optionally with various configurations, on various platforms (via cross compilers, or whatnot))
o) Runs a series of automated tests
o) Emails developers of specific modules or lines of code if there's an error in build or test (eg, using "svn blame" for line of code reference)
o) If no errors, runs the packager scripts and uploads them to a website
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
If the user was given a workaround, the answer that a fundamental fix is already in CVS is valid.
That is also a valid answer if he is given a script that will wrap the CVS checkout, autogen, configure, _dependency check& resolve_, make, make test, make install in a painless way. Or the url of a package for his distro.
I would urge developper to think about the workaround rather. The rage of the end user is just a symptom, the disease is that developpers fix the code and forget to help him with his problem. He takes the trouble of reporting and giving the software a second chance, so the developper should also do stg in his direction. Find a workaround or assist with CVS usage, et coetera. That has nothing to do with wether the development is paid or for free, neither with religions, it has to do with courtesy.
I started using Linux in 1993 when the SLS distribution fit onto 8 5.1/4"HD floppy disks that you wrote with RAWRITE. Even then there was an X server, vi, TCP/IP support, and most importantly XEYES, and even back then I was amazed such a thing could be built for free.
I took a few years off and started using it again with Slackware V9. This time I was dumbfounded. How in the world was this possible?? DVD player, Office software, various excellent servers, development IDEs, everything and still XEYES! How could this rise from a group of volunteers? This is something to be proud of. It's proof that human nature isn't totally self serving.
Now I read this. These comments. I can tell you that these aren't the attitudes that built Linux, but maybe they're what it created.
There seems to be two extremes and nothing else. On behalf of OSS developers I read "We don't owe anybody anything unless we get paid." On behalf of users I read "If you publish something then you're dedicated to support it or suffer painful death".
I'll be honest. These are legitimate viewpoints. Both of them. The first is an attitude you see in undisciplined children. 'I'll do what I want and owe nobody else anything. Damn the consequences. My world revolves around me.' The second is slightly more enlightened, such as 'Linux is awesome. I expect a quality free OS to replace Windows and developers to dedicate themselves to it. Myself, I'm not technical and too busy to contriubte."
There is no middle ground here. Luckily there is middle ground in reality otherwise this wouldn't still be working. It would be a shame if this rift got bigger driving Linux to a halt.
There is a middle ground, and I think that most of us live there. We don't expect perfection, we don't dedicate our lives to coding and patching, we experiment and try to get things to work, we enjoy seeing something we worked hard on used by other people and become important.
I remember the earliest Kansas City Linux Users Group (the first I found) postings from "users" were incredibly technical. Getting X windows to work involved terribly difficult calculations based on your monitor and graphics card's refresh rates. It took dedication and time to get a system running but what an accomplishment when you saw those xeyes (but that was about all you could run)
Now Linux is attracting less technical users. People that see the computer as a tool, as a means to an end, not an important toy. People that DONT want to compile a kernel and don't want to know how to. And people that want things to simply work, as they believe things do in windows.
More developers than ever are contributing at various levels of dedication and skill. Some publish a 1-time app that they wrote and have no desire to support and some are driven by providing something to the community that's needed and appreciated and are committed to supporting it.
And it takes both groups to make this work. Looking at your users as undeserving pests that provide nothing and should be grateful for what they get is wrong. But users should realise that they really don't DESERVE anything and SHOULD be grateful for what they get.
Users can't look at developers as software machines whos lives are dedicated solely to their application and should provide high quality support rapidly. But developers should realise that for this to function and grow that they need to support their application and try to understand what their users expect (and if they cant or don't want to fulfil those expectations then communicate it)
There's two ways to go. Developers can say "screw it, I'm not working on that app until my inbox is full of thank yous.", users can say "I'll keep flame-mailing this guy until he gets so pissed off that he helps me" (Good logic there)
Or we can step back, put our expectations back into p
Oh, you mean the PHP approach:
PHP devs: Is it fixed in this snapshot?
Me: No, still there.
PHP devs: Is it fixed in this newer snapshot?
Me: No, still there. BTW have you actually tried the 3 line reproduce code attached to this bug report?
PHP devs: Is it fixed in this snapshot?
Me: No, still there. Is it possible you could let me know which commits you think have fixed the problem so I can help you with this?
PHP devs: Is it fixed in this snapshot?
Me: ARGHHHHHHHHHH!
I have a sneaking suspicion that many OSS developers go out of their way to avoid documenting their projects on the hope that it will become popular (regardless), thus securing for themselves lucrative consulting fees.
I'm looking at you, Mr. Howard Lewis Ship, Independent Consultant.
Another aspect of OSS developer elitism. If you're not running the experimental, non-released CVS code, you've no idea what's going on with the software. There's always new features, fixes, and enhancements in the CVS dump, or even the non-release beta, and there's always a gaggle of users who absolutely must run the latest bleeding-edge zero-day version in order to be truly elite.
Ignore the fact that no one using the software for any serious purpose would sanely run non-release-quality software. OSS isn't for people to seriously use, but solely for geek cred.
OSS developers are like sysadmins. They don't care what the users want, because the users are idiots. Only developers really know what makes good software. If the developers haven't though of it, it can't be useful. This is why repeatedly submitted bugs/ERs that help day-to-day usage can sit stale in open bug trackers forever while some left-field chic feature that was some developer's pet idea and which has staying power on the order of a few months will suddenly appear as a priority in the next release beta.
Sadly, this notion of "the users want it, so we need to release it" is something I dare say the commercial software business understands a lot better.
Terrorists can attack freedom, but only Congress can destroy it.
I'm the devils advocate project manager who's also volunteered. X is what we need done, Y is our process for doing things and Z is the toolset. If a volunteer doesn't roughly fit that cookie cutter, then we are deeply appreciative of their interest but we have limited resources so we can't work with them at the moment.
I can see where you're coming from, but I think you're describing donating, not volunteering.boakes.org