Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The CVS Cop-Out

ScuttleMonkey posted more than 8 years ago | from the keep-the-users-happy dept.

486

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."

Sorry! There are no comments related to the filter you selected.

The CVS Copout.... (5, Funny)

LordEd (840443) | more than 8 years ago | (#15372591)

...was fixed 4 weeks ago! Didn't you get the memo?

Re:The CVS Copout.... (0)

remembertomorrow (959064) | more than 8 years ago | (#15372670)

The one about the TPS reports? Yes... yes I did.

Re:The CVS Copout.... (0, Offtopic)

flobberchops (971724) | more than 8 years ago | (#15372697)

Microsoft == Office Space. The only way you know you are doing a good job is by 10 middle managers being "visible" by sending out emails replying to each other saying "Yeah you rock, this is a great milestone achievement for this business unit! You rock! Go Girls!". Makes microsofties feel satisfied along with their 50 awards each performance review year worth 22 bucks each. VERY REWARDING! Microsoft is a GREAT PLACE TO WORK! THE WORLDS BEST COMPANY! Just ask Lisa Brummel, go girl! Oh, lets not forget management in the new reorg and redesign to make sure they get VISIBILITY AND REWARDS!

Re:The CVS Copout.... (5, Funny)

blowdart (31458) | more than 8 years ago | (#15372708)

And if it hasn't been fixed, well the source is there, fix it yourself. Geez.

Re:The CVS Copout.... (0, Troll)

flobberchops (971724) | more than 8 years ago | (#15372719)

Yes, because everybody is a Version control management expert! Lets all make changes to the code! Same old argument, GIMP "artists": If ya dont like it, GO FIX IT! Oh wait. theyre artists. NOT CVS EXPERT DEVELOPERS. Idiot.

Re:The CVS Copout.... (2, Funny)

Anonymous Coward | more than 8 years ago | (#15372734)

Next time, try checking out the humor patch, it might make your life better, ok? *roll eyes*

In related news... (2, Funny)

OpenSourced (323149) | more than 8 years ago | (#15372595)

Your check is in the mail too.

Re:In related news... (0)

Anonymous Coward | more than 8 years ago | (#15372618)

Let me be the first to name that the cheque cop-out. Don't worry, I'll submit it to CVS and immortalise myself. Feel free to submit a US patch.

don't forget... (4, Funny)

rivaldufus (634820) | more than 8 years ago | (#15372598)

"It's already fixed in subversion..."

The diplomatic response (4, Insightful)

AEton (654737) | more than 8 years ago | (#15372600)

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"

Re:The diplomatic response (4, Insightful)

djmurdoch (306849) | more than 8 years ago | (#15372635)

I suspect that that is the response this guy received, but he wants an argument.

Re:The diplomatic response (1)

nigelo (30096) | more than 8 years ago | (#15372702)

But this is 'Abuse' ... {snip} ... stupid git!

Re:The diplomatic (accurate) response (4, Insightful)

hbo (62590) | more than 8 years ago | (#15372641)

That's the ticket!

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.

Re:The diplomatic (accurate) response (2, Insightful)

Rakshasa Taisab (244699) | more than 8 years ago | (#15372755)

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 /.)

Re:The diplomatic response (2, Insightful)

MP3Chuck (652277) | more than 8 years ago | (#15372673)

Then again, the developers the author's complaining about are probably the same ones that, when approached with a problem in the code, say "Well, submit a patch then."

Re:The diplomatic response (4, Insightful)

Murmer (96505) | more than 8 years ago | (#15372684)

That's great, but a lot of projects don't even put out point releases; they're just in a constant state of CVS flux, and there's consequently no way at all for the user to tell what's been fixed when, to know what problems they've got or what problems have been solved. FFMpeg, I'm looking at you.

In fact, awesome, the FFMpeg people come right out and say [sourceforge.net] that if you're not using CVS to basically screw off and leave them alone.

They're not alone in this.

Re:The diplomatic response (5, Insightful)

Carewolf (581105) | more than 8 years ago | (#15372711)

Well. What kind of response did you expect when response that is has been fixed in CVS is not enough?

Fixed in CVS means:
1. We agree with you criticism
2. We have _already_ done something about it.
3. You can expect the fix in the next release.

The only time such an answer is not 100% perfect is when you are just looking for things to criticize to make them look bad. Then it is very unsatisfactory that it has already been fixed.

Re:The diplomatic response (5, Interesting)

lukas84 (912874) | more than 8 years ago | (#15372783)

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.

Re:The diplomatic response (2, Interesting)

Anonymous Coward | more than 8 years ago | (#15372850)

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.

Re:The diplomatic response (4, Informative)

El Cubano (631386) | more than 8 years ago | (#15372722)

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.

Which is how it should be. One thing the article says which struck me, What justification is there for ignoring the long-standing tradition of "release early, release often?"

Basically, he is complaining that they are not releasing early enough/often enough. I hate to break it to him, but not every project is a mozilla with daily snapshots or a Debian with a huge network of dedicate autobuild machines. Some projects are small and have only few core developers. Many of those people may have "real" jobs which leaves them only spare to work on their pet OSS project. He also seems to think that they bug should be fixed right away becuase it affects him. But then, isn't that how it always is?

"The bug that affects me is the most important and should be fixed immediately. I mean, I reported it yesterday. Why is the new point release fixing this grevious bug not out today?"

I guess if you have a bug that nukes your entire filesystem or something like that, you have a legitimate gripe. However, the vast majority of bugs are not serious at all.

This guy just has unrealistic expecations.

Re:The diplomatic response (5, Insightful)

Jeffrey Baker (6191) | more than 8 years ago | (#15372726)

A related and much worse problem is when the developers refuse to consider your bug report because you failed to test is against the latest CVS. "Well that's interesting but 2.7.92-pre2-test19-rr-gg-123 is over 16 minutes old. Could you please retest with ..." and that sort of thing. That is a true copout because the developers know damn well they haven't addressed the problem specifically, so there's no reason to believe that it's resolved in newer code. But it does give developers an excuse to delay addressing the problem.

Re:The diplomatic response (0, Redundant)

localman (111171) | more than 8 years ago | (#15372737)

You nailed it: it's all about presentation. Of cousre, I always hesitate to criticize or give advice to open source projects since I'm getting the stuff for free, but if they wanted to manage their customer relations better something like this would be how to do it.

Cheers.

Re:The diplomatic response (0)

Anonymous Coward | more than 8 years ago | (#15372748)

How about this, if they are kind enough to supply their name:
Shut the fuck up!
I have been working on this program on my own until it was fully functional, and I sometimes get patches nowadays from people who like the program. You haven't supplied me with anything except a reason not to give this out for free on the internet. The bug you described will thus be made worse in the binary release, and only the source release will get fixes from now on. I have also added a clause to my license which forces all versions of the program to print out "[John Smith] (johnqsmith@example.com) is a worthless human being" at start up.
Have a nice day!

Re:The diplomatic response (3, Interesting)

tacocat (527354) | more than 8 years ago | (#15372769)

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.

Not unique to open source (4, Insightful)

smackjer (697558) | more than 8 years ago | (#15372601)

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?

Re:Not unique to open source (4, Insightful)

diamondsw (685967) | more than 8 years ago | (#15372640)

However, Microsoft and other upgrades are binaries, and installable by end users. Telling a normal user to download source code, ./configure, make, make install (and you better hope nothing broke in the autoconf) doesn't cut it. Downloading a nightly binary, that would be acceptable (see the WebKit project for a great example).

This is particularly egregious in projects that never release final binaries except once a blue moon. It's even better when CVS is down, as SourceForge was for a while last month, and FFMpeg is as of this post...

Re:Not unique to open source (3, Informative)

tonsofpcs (687961) | more than 8 years ago | (#15372674)

Read: Nightly Builds [slashdot.org]
Not everyone releases them, but those projects that do, "hey, that was fixed yesterday, visit the nightlies page (e.g. http://nightlies.videolan.org/ [videolan.org] ) and grab the latest"

Re:Not unique to open source (2, Interesting)

Mignon (34109) | more than 8 years ago | (#15372823)

Not everyone releases [nightly builds]

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.

Re:Not unique to open source (3, Interesting)

Znork (31774) | more than 8 years ago | (#15372731)

"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...

Re:Not unique to open source (1)

mindstormpt (728974) | more than 8 years ago | (#15372675)

It's not the same. While updating Windows is easy, checking out the source and compiling the application is not. I won't say most users can update Windows on their own, but at least some part of them can. How many non-techy computer (mainly Windows) users can compile a program?

That would not be the same as Microsoft telling us to upgrade, it would be the same as telling us that it is already implemented in the current source. We don't have access to Microsoft code, and most users don't know how to access CVS. The end result is the same.

new versions (2, Insightful)

Anonymous Coward | more than 8 years ago | (#15372603)

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.

Re:new versions (2, Insightful)

tonsofpcs (687961) | more than 8 years ago | (#15372650)

It's called a nightly build. Many projects have this, usually around midnight or 1am in the project's home country's timezone or in one of their choosing based upon userbase.

Eh what ? (0, Redundant)

Salsaman (141471) | more than 8 years ago | (#15372606)

...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."

You mean it leads to retrospective resolution ? That is indeed strange !

What's the point here? (0, Redundant)

QuietLagoon (813062) | more than 8 years ago | (#15372608)

Aside from it being a slow news day.

Re:What's the point here? (0)

Anonymous Coward | more than 8 years ago | (#15372812)

I think his point is that all Free Software developers should have though of adding every possible feature ever before the first release. That or that the aforementioned developers ought to have timemachines.

BS (2, Insightful)

republican gourd (879711) | more than 8 years ago | (#15372609)

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.

Re:BS (5, Insightful)

mikeplokta (223052) | more than 8 years ago | (#15372642)

The problem is that developers (open source or not) tend to think that "committed to CVS" == "fixed. Once it's been tested, documented and released, then it's fixed -- until then, a fix is simply in the early stages of development.

Re:BS (3, Insightful)

ivan256 (17499) | more than 8 years ago | (#15372704)

I don't think you're right. The problem is that you take it to mean they think that committed to CVS is the same as fixed. They mean actually mean: "I've taken care of it as much as I plan to for the moment. I heard you, so stop bothering me."

Re:BS (2, Insightful)

Zed2K (313037) | more than 8 years ago | (#15372709)

Exactly! Which the open source developers would know if they actually took responsibility for their open source work. Most of them don't. They do if for free and expect people to just "accept it" and then when people don't they pull out the whole "well its free" cop-out.

Re:BS (1)

iCEBaLM (34905) | more than 8 years ago | (#15372782)

I think you missed out on the whole "THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU" part in almost every OSS license. (Quoted verbatim from the GNU GPL v2)

This means, in effect, that they do not have any responsibility to you, period. You can either accept it or not use it. This is not a cop-out, this is the way it is.

The problem is that people like you believe you are entitled to something. You are not. Get over it.

Re:BS (3, Insightful)

0racle (667029) | more than 8 years ago | (#15372720)

Fine. Then check out the patched sources and start testing it.

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.

What would you prefer? (4, Insightful)

kevin_conaway (585204) | more than 8 years ago | (#15372611)

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.

Re:What would you prefer? (5, Insightful)

chill (34294) | more than 8 years ago | (#15372750)

Want bugs fixed faster? Quit bitching and start testing.

Typical I-have-no-life-but-my-project response.

Here is the typical "test" from a user perspective.

1. Website has dire warnings about stable vs unstable, so user gets stable version.
2. User finds bug and reports it. Often they provide no useful information other than "feature X doesn't work".
3. Odd are, user just e-mailed someone which means this now needs to be entered into development bugtracking system, like bugzilla. User is pointed to bugzilla and/or proper bug reporting method.
4a. If the user is worth a damn, they will attempt to report it properly.
4b. Other users bitch about FOSS software quality and leave to flame on /.
5. User spends days trying to figure out the proper way to report a bug via bugzilla. Here is a tip to developers -- Bugzilla is NOT USER FRIENDLY AT ALL if you are not a developer. It sucks like a Dyson. If you're a developer, KNOW WHAT YOU ARE DOING and use it daily, it is great. If not, it is a bitch.
6. User offers to test, gets development version.
7. User finds out that all the real action is in CVS/Subversion and spends the next 6 weeks trying to figure that mess out.
8. User finally gets CVS source, takes the next few days trying to understand the code.
9. By the time user understands the code enough to make a change, someone else has changed something and they have to resync. Loop to 8 at infinitum.

Moral of the story? Testers are NOT developers. If you want quality TEST people then never EVER send them to Bugzilla and never EVER give them CVS/Subversion. Give them a SIMPLE form to fill out for reporting bugs that can then be parsed by someone who knows Bugzilla or your bug reporting system.

Don't assume testers have a development toolchain. Don't expect them to use CVS or compile/link anything. Give them a .tar.gz or .zip of an executable. THAT they can test.

If you're moving so fast in development that this is unreasonable, then don't be asking for non-development testers.

Re:What would you prefer? (1)

Snowhare (263311) | more than 8 years ago | (#15372751)

"also allow users to test the code"

That is actually his complaint: Putting it in CVS DOESN'T allow most users to test the code. Putting it in a downloadable binary, tarball, RPM, SRPM or other essentially self-contained form DOES. Too many developers check things into CVS and ignore the fact that CVS/SubVersion/Other Revision Control System is a guarantee that you won't be able to readily obtain and compile it for the average person. There is a distinctly non-trivial learning curve associated with even the simplest RCS. As simple a thing as exporting a tarballed nighly snapshot of a CVS system helps non-developers tremendously.

better problem if examples (real) were given (5, Insightful)

yagu (721525) | more than 8 years ago | (#15372612)

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:

At the complete other end of the spectrum is a kind of app that we all love to hate, the audio player. The task of the audio player is so complex that almost all of them rely on a mountain of I/O and processing libraries to support the dozens of sound formats, metadata, synchronization and modification, effects, and management that we all expect.

But that level of complexity just about guarantees that when a bug hits Rhythmbox and robs it of its ability to play *.m4b files (to make up an example), the mass market won't see *.m4b playback in Rhythmbox again for six or more months.

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?

Re:better problem if examples (real) were given (1)

LearnToSpell (694184) | more than 8 years ago | (#15372663)

You want a real-life example? Gaim. They don't even bother with cop-outs anymore. There's zero response to any kind of "when" question. I understand "it's ready when it's ready," but the total lack of communication is just stupid.
A lot of you have noticed that while we typically release every three weeks, we haven't had a release in a while. We've shifted all our efforts to finishing Gaim 2.0.0. Gaim 2.0.0 has a ton of great features, fixes every problem you've ever had with Gaim, makes drastic changes to huge parts of Gaim---especially status, includes three new protocols, and does a bunch of other amazing stuff. We're looking to feature freeze at the end of this month and release a month or so later, so be sure to get on our cases and make sure we get it finished.
That'd be from October 12th, 2005. Yes, seven months ago. Meanwhile, we're going to be going through the *second* Summer of Code without a stable release including some of the major accomplishments, like file transfers actually working.

Re:better problem if examples (real) were given (1)

Slack3r78 (596506) | more than 8 years ago | (#15372824)

Except for the regular updates and multiple Gaim 2.0 beta releases in that time?

Meanwhile, we're going to be going through the *second* Summer of Code without a stable release including some of the major accomplishments, like file transfers actually working.

To quote the famous owls: O RLY?

What's this then? [sourceforge.net] Or the fact that I was just transfering files over GAIM via Oscar last night?

This, of course, is ignoring the fact that Oscar file transfers are totally undocumented by AOL meaning they had to be reverse engineered, which isn't easy. It sounds like Summer of Code accomplished exactly what it was supposed to to me.

Article in CVS (1)

dominick (550229) | more than 8 years ago | (#15372619)

This article was posted in CVS like four freakin weeks ago.

shining example: mplayerhq.hu (0)

Anonymous Coward | more than 8 years ago | (#15372620)

Mplayer: critical bug, fixed 2006.02.15 in CVS, no fixed release available. Thanks for nothing, new mplayer team.

Oh .. I get it. (5, Funny)

gru3hunt3r (782984) | more than 8 years ago | (#15372622)

(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.

Re:Oh .. I get it. (0, Flamebait)

Zed2K (313037) | more than 8 years ago | (#15372692)

Actually people want software that works and someone to provide more support than "fix it yourself". Open source software sucks and the mentality of their developers sucks. They wouldn't last in a real company where they actually have to support the work they do. If you are going to do it for free then don't half-ass it, do it right the first time.

I'm tired of coming across something that won't compile correctly or encountering a bug. Then when you research it you come across 100 posts of people asking the same question and getting the same response of fix it yourself or do a search the answer is already here. You know what? I've got a job that pays money, I'm not about to waste my time trying to learn the code base for a one off project that looked interesting. 9 times out of 10 I'll move on. If the answer already exists why hasn't it been incorporated into the source? Or looking for documentation and the only thing that exists is: ./Configure
make
make install

Thats BS. Thats the reason the majority of open source developers are assholes and they get the bad rap that they do, because they deserve it 100%.

Re:Oh .. I get it. (2, Insightful)

xRobx (795021) | more than 8 years ago | (#15372770)

A lot of open source developers do work at "real" companies, and they work on an open source project on their spare time. Nobody owes you anything, they release their work because they want to.

Re:Oh .. I get it. (4, Interesting)

Todd Knarr (15451) | more than 8 years ago | (#15372786)

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.

Re:Oh .. I get it. (0)

Anonymous Coward | more than 8 years ago | (#15372834)

Actually people want software that works and someone to provide more support than "fix it yourself".

People who want that are free to choose software that provides it. Some open source software comes into this category. Some commercial software doesn't; when was the last time Microsoft fixed a bug in Word just because you asked them to?

Open source software sucks and the mentality of their developers sucks.

And you would never sink so low as to make a sweeping generalisation, now, would you?

If you are going to do it for free then don't half-ass it, do it right the first time.

The ludicrous implication is that you have no problem with people "half-assing it" when you're actually paying them for their hard work.

Get this into your head: this is not about you. Most of the people who give away their work for free are not doing so because they want you to be impressed, or because they want you to like them. They are doing so because they think someone else might find their work useful. If you don't find it useful, then don't use it. If you don't like any of the free options, then pay for something you do like.

You know what? I've got a job that pays money

Oooh, I'm really impressed.

I'm not about to waste my time trying to learn the code base for a one off project that looked interesting. 9 times out of 10 I'll move on.

Yeah, that'll show them.

the majority of open source developers are assholes and they get the bad rap that they do, because they deserve it 100%.

If the majority of people reporting bugs are like you, then I'd rather be an asshole.

Re:Oh .. I get it. (2, Insightful)

basic0 (182925) | more than 8 years ago | (#15372699)

I have a bit of a 1980s Steve Jobs attitude towards software and developers: if it doesn't work or if it sucks really bad, don't release it to the public. Maybe *you* think you're programming something for yourself, but when you post it to this website and that website and get it included in Linux distros, end users will be using it and expecting it to work. If you can't take the heat, etc...

Re:Oh .. I get it. (2, Insightful)

rbarreira (836272) | more than 8 years ago | (#15372784)

I know that was a joke, but it made me think of something anyway:

People should only develop free (as in beer) software IF THEY REALLY WANT TO. If you're not prepared to not get anything from it, don't do it. If someone complains politely about a problem and you feel angry or make an angered reply, it's because you should have never done it for free or no longer want to do it.

Re:Oh .. I get it. (1)

tomjen (839882) | more than 8 years ago | (#15372864)

That could be the reason - it could also just be that you love to develop and know that people use your program. Users who report bugs you already know about does not help you development efforts nor do they help others - so you might get pissed.

Oh..kay Oh..kay... slowly! (0)

Anonymous Coward | more than 8 years ago | (#15372623)

1) What is the article about? Cops who have problems with using CVS?

2) That is Nerd news!!! I thought /. was a FUD site since Zonk and ScuttleMonkey joined in?

3) Subversion, anyone?

Hmm.... (5, Funny)

Newer Guy (520108) | more than 8 years ago | (#15372625)

And I thought this thread was about a drug store chain getting rid of their security officers......

Poor Communications skills (1)

Ryouga3 (683889) | more than 8 years ago | (#15372627)

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.

It's one thing to have it fixed in CVS (1)

Z00L00K (682162) | more than 8 years ago | (#15372631)

or whatever version control system you use another is when it is integrated and released in a tested release. There are a myriad of things that occurs in a version control system and not all modifications are what you want in a release.

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.

It's not so much a cop-out,... (2, Informative)

Anonymous Coward | more than 8 years ago | (#15372632)

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."

Excuse me? (5, Insightful)

ivan256 (17499) | more than 8 years ago | (#15372645)

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.

Re:Excuse me? (-1)

Anonymous Coward | more than 8 years ago | (#15372797)

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.

So you're comfortable releasing code that is broken, so long as it isn't broken for you. It's no wonder you've decided not to attach your name to the source. I wouldn't want to acquire a reputation for distributing shoddy product either. Those real life employers and clients might get the idea that you're unprofessional.

Re:Excuse me? (0)

Anonymous Coward | more than 8 years ago | (#15372828)

So you're comfortable releasing code that is broken, so long as it isn't broken for you.

By definition, it isn't broken if it works for it's intended purpose. It's intended purpose is what he wanted it to do, not what some asshole from the other side of the planet thinks would be neat if it did.

Re:Excuse me? (-1)

Anonymous Coward | more than 8 years ago | (#15372852)

The Microsoft answer to bug reports. Very respectable.

Re:Excuse me? (0)

Anonymous Coward | more than 8 years ago | (#15372862)

There's a difference between developing and selling something intended to be used by the general public, and developing something for yourself and giving it away in case it might be useful for someone else. Or might not.

But I don't expect you to grasp the difference, any more than I expect you to grasp the difference between a bug report and a feature request.

Re:Excuse me? (0)

Anonymous Coward | more than 8 years ago | (#15372848)

I could care less

Then why don't you?

And the flip side... (3, Insightful)

jnik (1733) | more than 8 years ago | (#15372646)

"If you use the CVS, don't expect support." Public CVS access is great--it gives people an opportunity to try out new things and invites outside developers. But it's really only part of "release early, release often." Keeping a stable version reasonably up-to-date keeps users happy (which in turn results in more contributors to your project) and, in my experience, results in better code. Plus, it reduces support headaches.

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.

Re:And the flip side... (1)

Homology (639438) | more than 8 years ago | (#15372860)

"If you use the CVS, don't expect support." Public CVS access is great--it gives people an opportunity to try out new things and invites outside developers.

As an annectode: When OpenBSD forked from NetBSD it was uncommon to have public access to CVS repositories, and whence the Open in OpenBSD. So today we take public CVS access for granted, but was not always the case, even for open source projects.

what's the alternative ? (1)

jimbob1859 (954480) | more than 8 years ago | (#15372648)

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.

Easily solved (1)

Damek (515688) | more than 8 years ago | (#15372655)

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!"

Re:Easily solved (1)

Chandon Seldon (43083) | more than 8 years ago | (#15372772)

The problem can also be solved by users making that translation in their head, so those of us who would consider a CVS build if appropriate aren't screwed out of useful information.

Re:Easily solved (1)

cb372 (974039) | more than 8 years ago | (#15372800)

Exactly. The first rule of dealing with users: Never Tell Them The Truth. (The second rule: if you absolutely have to tell them the truth, make sure your explanation is so long-winded and jargon-riddled that they'll know not to ask any more questions) ;)

That's not the most annoying... (5, Insightful)

avalys (221114) | more than 8 years ago | (#15372657)

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?

I got the CVS cop-out from the cscope maintainer (5, Insightful)

rklrkl (554527) | more than 8 years ago | (#15372661)

Saying it's fixed in CVS is fine, providing there's regular releases afterwards with those CVS fixes in. I reported a problem with cscope [sourceforge.net] to the maintainers of that package (resizing the window causes the application to exit immediately - a pretty major flaw for a stable release) and was told that "this was fixed a long time ago in CVS". Yes, I even sent them a one-line fix (ignore SIGWINCH signal) as a temporary measure too, so I did try to get them to fix their stable version without having to roll out the CVS-based one instead.

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.

Like Hollywood says... (3, Insightful)

patio11 (857072) | more than 8 years ago | (#15372668)

... 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".

Re:Like Hollywood says... (0)

Anonymous Coward | more than 8 years ago | (#15372757)

An impressive list of seven things you want from developers. What are you going to provide in return?

Re:Like Hollywood says... (1)

jelle (14827) | more than 8 years ago | (#15372795)

"other things OSS as a class could stand to do better"

You mention documentation a lot. The only to do that right for the end user is to have expert users write the documentation, not the developers. The end users are usually the lazy bunch of an OSS projects, hence the end-user documentation sucks. To 'fix' that, the expert users of the software of the project need to chip in and make documentation. If there are many expert users, and no small group is willing/able to do the whole thing, then a Wiki can be of tremendous use.

Similar with testing and release. OSS developers don't usually take much time to do that, because they are busy developing (whining about that won't change that, this is OSS and the developers are volunteers). Especially because of the usability and end-user experience arguments, testing and release is more an expert-user task than a developer task.

I made that statement about the documentation, because for the developers a tremendously large portion of the documentation load is carries by the 'Source' in 'Open Source', or as more commonly said: UTSL... "Use the Source Luke!". I've even looked at things like the libc source to find out exactly what is what, where, and why. Documentation doesn't get more precise and up-to-date than that. UTSL works, if you speak the language of a developer.

The solution to the CVS cop-out is... (2, Funny)

donaldGuy (969269) | more than 8 years ago | (#15372672)

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"

Not a cop-out, just a fact (4, Insightful)

Todd Knarr (15451) | more than 8 years ago | (#15372691)

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.".

Re:Not a cop-out, just a fact (1)

uglyduckling (103926) | more than 8 years ago | (#15372806)

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.

But what they should do, if it's a serious bug, is fix it in the current stable branch and do a new point release that includes that bug fix. The CVS might have hundreds of new features and take months or years to arrive whilst those using the stable version are waiting. If a project is mature and/or user-focused enough to have a stable/development separation so that they expect people to mainly use the stable version, they should be prepared to backport major bug fixes or fix directly in the stable branch. If they're not ready to do that then they should stick to being a 'developers-only' project for the time being.

Re:Not a cop-out, just a fact (1)

PenGun (794213) | more than 8 years ago | (#15372825)

User focused projects are fairly rare in free software actually. If you need your hand held you may be better off with a user focused OS.

    PenGun
  Do What Now ??? ... Standards and Practices !

I don't understand the problem. (1)

Aurisor (932566) | more than 8 years ago | (#15372710)

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.

Huh? (1)

Black Parrot (19622) | more than 8 years ago | (#15372718)

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...

Beats the alternative, which is untested software (1)

@madeus (24818) | more than 8 years ago | (#15372721)

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.

Did you ever think that maybe it's true? (1)

i_want_you_to_throw_ (559379) | more than 8 years ago | (#15372733)

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 [google.com] you can do with them.

Re:Did you ever think that maybe it's true? (0)

Anonymous Coward | more than 8 years ago | (#15372761)

if there's a real a CVS (the drugstore) copout

Computer vision syndrome leads to
Cyclic Vomiting Syndrome remedied with
CVS Pharmacy pills that cause
Cardivascular System problems tested by
Chorionic Villus Sampling.

--
Content Venue Sans
OFFTOPIC (-1)

CVS "cop-out" (1)

bmk67 (971394) | more than 8 years ago | (#15372743)

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.

The author wants binaries... (1)

(H)elix1 (231155) | more than 8 years ago | (#15372758)

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.

I seem to be saying this a lot lately... (4, Informative)

biglig2 (89374) | more than 8 years ago | (#15372767)

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!

Re:I seem to be saying this a lot lately... (1)

colmore (56499) | more than 8 years ago | (#15372831)

You also gain the skills of using CVS and a compiler.

I'd really suggest that novice linux users out there spend a couple of hours learning enough CVS or SVN to get their favorite package's souce-tree, and then learn how to compile it (probably just ./configure; make install)

You'll learn a bit about your machine and the linux environment, comilers and versioning tools are useful to know about even if you don't write code, and if you do, you're one step closer to knowing enough to help out on OS devteams.

There's another name for CVS Copout.... (1)

jforest1 (966315) | more than 8 years ago | (#15372768)

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.

The deployment pipe often gets neglected in OSS (1)

Qbertino (265505) | more than 8 years ago | (#15372813)

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 [rubyonrails.org] and end-user management [joomla.org] .

I have an idea... (0)

Anonymous Coward | more than 8 years ago | (#15372830)

"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...

Wanted: Someone to go back in time with me .. (2, Funny)

DirtyShaman (976105) | more than 8 years ago | (#15372837)

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..

this is the wrong problem.... (1)

nblender (741424) | more than 8 years ago | (#15372844)

In closed-source-software, when you complain that feature foo is broken, you get told "That will be fixed in version bar.x.y". They've already fixed the bug in their SCM but you won't know that until bar.x.y comes out and you buy the upgrade, or your maintenance agreement allows you to retrieve that version when it's released.

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_.

Fixed in CVS is better than... (1)

Tweekster (949766) | more than 8 years ago | (#15372845)

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)

Dead easy solution (1)

Eli Gottlieb (917758) | more than 8 years ago | (#15372854)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?