Please stay nice. If you know how to fix it, add the code yourself and let them know, else refrain from attacks.

The nice version of that answer is available at Einstein - I find I write polite answers in the evenings, and grumpy answers in the mornings. Sorry, that's just the way I'm made :-)

As you know, I reported this problem on 20 October, over a week before v6.10.17 was declared "recommended" on 29 October. I accept and appreciate that it isn't a show-stopper for the vast majority of BOINC users, and I can live with the decision to release regardless. But I have two comments on the process.

1) When a new version is released with known problems, even if they only affect a small number of users, I think there should be a caveat in the release notes: "Vx.yy.zz released and recommended. There's work still to do in [some obscure area] - hold off upgrading if you run [some special case]"

2) There is a very strong human tendency - I know, I've written software and had it released to the public - to ship it out of the door, heave a great sigh of relief, and turn your mind to something else - anything else - to recharge your batteries before the next bout of coding. But I've had to try and resist that tendency in my own work: the hours or days after a software release are the time when the new code is exposed to the widest spectrum of new environments in the shortest time, and almost inevitably untested wrinkles will reveal themselves. As far as possible, the helpdesk and debug teams should be geared up to handle this entirely predictable workload bulge.

Rom Walton, October 26 2009 wrote:

A showstopper is a bug that causes the client software to crash, the client to overload the computer, or trash the work queue. At this point bad bugs that also reproduce on 6.6 or 6.8 should be reported, but more than likely will not stop the release.

It does nothing of the sort, hence why it wasn't classified as a showstopper.

1) When a new version is released with known problems, even if they only affect a small number of users, I think there should be a caveat in the release notes: "Vx.yy.zz released and recommended. There's work still to do in [some obscure area] - hold off upgrading if you run [some special case]"

Here are the release notes: http://boinc.berkeley.edu/wiki/Release_Notes
Make a wiki account if you haven't one yet and add your objections/notes to the release notes, that's what they are for.

As far as possible, the helpdesk and debug teams should be geared up to handle this entirely predictable workload bulge.

I am sending constant reports in to the developers, on just about everything I find that other people - including you - report on anything they find amiss with the released software, as well as have a daily chat (sometimes even more than one) with Rom on what's the most reported/needed thing out there.

Hence how we now figured out that the minimum driver for CUDA with BOINC 6.10 is 185.85 (CUDA 2.2), hence why I have written that warning in a lot of places and hope others relay that warning to the other forums out there that use the technology.

I'm ready to test when a new version is compiled - hasn't appeared yet.

Here is a link to the page explaining how you can get the source code.
Here is a link to the page explaining how you can build your own client from the aforementioned source code.

After every major release there are always complaints from people, thinking they found a bug while they didn't read all the links from the download page. Complaints are fine as long as they have merit.
You think you found a bug? That is fine, explain all you can to me or others who know a thing or two about this software.

The attacks on the developers isn't fine by my book. Without their work you wouldn't have a new client to play around with.

When you know you post fine answers in the evening and are grumpy in the morning, then either don't post in the morning or learn to keep your fingers from typing more than is necessary when you help people. The amount of times I have rewritten posts, even after immediate posting, are numerous.

When you feel you're in a feud with the developers, keep it at them (on the email lists or privately). Don't lay that burden on the volunteer you're trying to help. It doesn't look too nice to the outside world.

---

Oh dear. You won't mind changing that title to "mild exasperation", would you, while I go out for a walk to clarify my thoughts on the equivalence of 'politeness' and 'lying'?

All I am saying is that you don't need to post it in reply to someone who is asking for help. You want to rant? Let's make this a rant thread, there will probably be others coming along as well to post their complaints and rants in. Heck, you may even see me make an entry. Oh damn, I'm doing it already.

As an example: You wouldn't like it either when you go to the hospital to get help for a big head gash, making you spill blood everywhere, that the nurses there help you and en passant rant to you about the added workload they got with less people, things you can't do anything about and aren't (at that time) interested in.

Something of the same can be said about all those people ranting against the new credit system proposal. They themselves can't come up with anything better, they refuse to go for changes, all they see is that they'll be hurt in procuring more of the hyper-inflated amount of credits they need to get per bit done, science be damned.

And it's always this same group of maybe 50 people who will do anything in their power to make projects not use something that's possibly better. They'll complain that of the 1.5 million people only 380,000 stayed behind to do actual science, while they forget that anyone who might be the slightest interested in any project, reading such a thread will scare them away. That the other 379,950 people don't mind and continue to go about their business is also something they overlook. Me, me, me, me.

Would you want to be a part of any software project where there are people calling the developers whatever comes to mind? Where only their opinion is the correct one and if you go against it, you're automatically branded a Kredit Kop or worse?

Probably they forget that without the developers, they wouldn't be doing anything for these projects. There would be no BOINC, there would be no (hyper-inflated) credits, Seti would be long dead. Perhaps that at the next timeline split we should let it die and see what happened to everyone. ;-)

---

In my part of the world, p y f o is a relatively mild exhortation to hurry up or get a move on. Thinking about it during my walk, and observing that the water level in my local canal has dropped 10cm since I walked that way last week, I remembered that it may have a rather more urgent connotation in the Dutch stereotype. Apologies if my English english idiom jangled a few cross-cultural nerves.

In terms of product launches, I'm a great believer in 'launch when ready', but not before. Parhaps it dates back to the discipline I was put through with our own product launch.....

We hired one of the ornate function rooms in a grand Victorian town hall (Wakefield, in our case), and hooked up a PC - probably a 286 or 386: this was 1992 - to the first big ceiling-mounted three-lens Barco projector any of us had ever seen. The project Director talked the great and the good - representatives of the national bodies who had pur up the development money which enabled the project to get off the ground in the first place - through the purpose and functions of the software: my role, as the one and only single-handed programmer, was to act as 'keyboards' for the day and press the right buttons. You do not want an error message to appear on the projection screen under those circumstances!

But even with that level of preparation (and believe me, there was some thorough testing before we got anywhere near the Town Hall), we still expected problems and made sure we stood by the phone for the first few days after the initial orders and complementary copies were posted out. I've looked back through the original bug report forms I jotted down in the early days: "Data files [text] found to be in WordPerfect format - their printer settings" - "No access to LPT1: - uses Netware queue capture" - "Machine type unknown, but AT class - presume HD drive, but using double-density 96tpi 5.25inch disks - probably incompatible with drive" - "Not enough memory - config.sys installs non-standard RAM disk, which reports taking up 384KB".

And so on. We probably learned more about the variety of computing environments in those few weeks than at any time before or since. And it was our job - my job - to make the software work in as many of those environments as possible. We accepted the responsibility to deal with the problems, even though many of them - as you can see from the list above - didn't stem directly from bugs in our software.

And since the organisation I was programming for is stull running eighteen years later, we must have done something right.