So far there have been 310 views of this thread (Alpha Client Release---POLL). Not one person has admitted they didn't know that risks were involved. There was one person (Puffy) who admitted "I knew the 4.14+ releases wern't the cream of the crop". Also, This thread has been on the board almost as long as the "Boinc 4.19 released...Come and get it thread". That thread is slowly sinking down off the page. What this means is that the Group of viewers that would have seen that thread have also seen this thread. This gives any harmed party a chance to respond, and voice their pain.

I believe that there must be at least one or two who didn't know but were to ashamed to admit it on these public threads. But was damage done to either of those "Supposed" 1 or 2??? We may never know. What we do know is:
1) the vast majority agree with me in that they want to help out the science in whatever manner they can.
2) The number of people hurt by the posting of new release messages to this board is practically nil.
3) That with more people test driving new releases; the bugs are worked out faster and more reliably than can be achieved through a limited number of participants. (there are more varieties of systems and set ups involved in the larger grouping)

I agree with Slavko who wrote
"The biggest problem is that only 1% of all users are really reading Message Boards at all (I mean periodical, daily, or at leat every 48-72 hours). I really know all, lets say 100, people from forums and let assume that another 1000-5000 people are reading it at least one per week. But here are more then 80.000 people involved". We 1% who use these boards are developing better clients for the thousands of others who faithfully crunch away trusting Berkeley to provide them with stable software. If a (just one) version hits public release that has a minor bug causing connection problems, or client errors, or some other defeciency that can cause MAJOR loss of science to Seti or other projects. The cost of lost WUs or delays in credit to we few is the price we pay to ensure the thousands of others don't loose theirs.

I'll keep that thread bumped to the top over the coming days to give everyone a chance to see and to respond.

This thread has produced some "Brilliant" ideas about issues that Berkeley might want to introduce later such as "Maybe have a box pop up telling the user that the project has a new client available with a short description of the changes. Posted by Allan Taylor.

The improvements that can be made are all found in these threads and contributed by "We Few" who frequent these board.

Thanks again for your help.

---

Hi

I agree in most cases.
I´m running every Alpha client since 4.53 and posted about it.
I got more critical response that i thought, but i now know its better to post more news.
The Alpha client runs smooth enough to let the risk at a minimum to use it.
First step what i do is when i´m runninig a new cli is turning of network access to leave the risk loosing results.
Than checking the up and downloads twice a day.

greetz from Germany

Mike

Boinc Beta Tester since March 2003

---

With each crime and every kindness we birth our future.

> 1) the vast majority agree with me in that they want to help out the science
> in whatever manner they can.
> 2) The number of people hurt by the posting of new release messages to this
> board is practically nil.
> 3) That with more people test driving new releases; the bugs are worked out
> faster and more reliably than can be achieved through a limited number of
> participants. (there are more varieties of systems and set ups involved in the
> larger grouping)

Well said, actually the whole thing was good ...

Even an official release can have issues, do you remember the hoo-row when someone found out that there were something on the order or 10,000 to 45,000 known issues with Windows 95 (If I remember the version correctly)?

Virtually all of these we cosmetic items and, for all its flaws, and there were many, 95 was better than what had come before.

If we were to get mad we should be mad about Microsoft compromising the kernal between 3.51 and later ... running device drivers in ring 0, get a clue!

Sorry pet peeve activated ... I feel much better now ...

---

> 3) That with more people test driving new releases; the bugs are worked out
> faster and more reliably than can be achieved through a limited number of
> participants. (there are more varieties of systems and set ups involved in the larger grouping)
>
I agree with everything you said but think that a possible addition should be that a board should be added that handles these pre-release versions. That way the rest of us don't have to wade thru all the people with problems. If there was a pre-release specific board it could start out with all the usual disclaimers and then expand into both the posting of the locations of the software and the problems found while using it and their possible solutions.

---

There HAVE been several users who have expressed frustration over all the different versions. Had you at least waited 24 hours before posting all the "new client available" threads, some of this may have been avoided. Also I think the idea behind the poll was a bit flawed. Myself and a few other people have made sure that people DO know that these releases are risky. I have posted on the order of 5 or 6 messages to that effect. My main complaint is that the original author of the thread doesn't include this information but rather portrays it as a "new" version of the BOINC client. Keep in mind that a LOT more people read these boards than actually participate in them. All I'm trying to do is make sure new users and others who don't have a clue about how BOINC works aren't led to install a buggy client because it is announced as "new" here. They may do so and then not look at these boards for 3 weeks. I do recall someone recently claiming that he was "forced" to upgrade to an unstable build and then it broke things. Where did he even hear about the alpha build if not here?

I am still of the opinion that the alpha clients shouldn't be talked about as much as they are here however I would be much happier if you simply include a "surgeon general's warning" in every thread about a non-stable client. The primary source for bug reports to the devs is NOT this forum. All of the problems with the 4.14-4.18 clients were reported within minutes or hours on the developer mailing list. There is way too much garbage on these message boards for it to be used as an effective bug reporting tool. Yes, there have been a few reported here but not nearly as many as have been reported through other channels so to view the threads as a bug reporting tool is not very accurate.

---

A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site

I'm with Toby. Any posting of "new CC release" that is still alpha/beta, should have the disclaimer stating as much. It only takes a few extra seconds, and could save some poor unsuspecting soul much aggravation. To say nothing is irresponsible behavior. Sure, a large number of the users are savvy enough to know whether it is a public release or not, but you're always going to have some that don't know any better. They see the post and follow the link. If they have a bad experience, they will most likely just quit the project.

If it were up to me, only alpha test members would be able to download the alpha releases, but the dev team obviously doesn't seem to think so. I would also get the beta project back up. (beta .exe also limited to beta users) That would limit public confusion. But I'm not dev, so it's really a non-issue.

---

Toby
I know you have the best interest of Seti/Boinc at heart. It shows in your passion. The passion that is visible in your posts.

> There HAVE been several users who have expressed frustration over all the
> different versions.

I agree, Heck, I'm one of them. Sometimes I hate my Bob Newhart style of humor. The title of my post was "HMMMM...Boinc 4.19 released.....Come and get it". The HMMM part is indicating of my skepticism of yet another update. I mean, there had been 3 days of updates. It was supposed to be humorous. The Boinc 4.19 thing is self explanitory. The "come and get it" was a reference to old days when Mom (ok, my mom didn't but maybe hers did) would ring the dinner bell. I found it funny that everyone would once again commence the downloading and installing yet one more time. By this time I didn't really thing another "use at your own risk warning was necessary.

>Also I think the idea behind the poll was a bit flawed.

Ditto, I tried to discuss the flaws, but sure I didn't discuss all of them. There are to many variable for it to be scientific, heck, I'm an electrician with an associates in electronics, NOT a scientist.

>Myself and a few other
> people have made sure that people DO know that these releases are risky. I
> have posted on the order of 5 or 6 messages to that effect.

Isn't this community great. When someone drops the ball, someone else will help them out. Thanks.

>My main complaint is that the original author of the thread doesn't include this information but
> rather portrays it as a "new" version of the BOINC client. Keep in mind that
> a LOT more people read these boards than actually participate in them.

Agreed on all counts. If I ever do it again, I will include such a warning.

>All I'm trying to do is make sure new users and others who don't have a clue
> about how BOINC works aren't led to install a buggy client because it is
> announced as "new" here. They may do so and then not look at these boards for
> 3 weeks. I do recall someone recently claiming that he was "forced" to
> upgrade to an unstable build and then it broke things. Where did he even hear
> about the alpha build if not here?

That person was Gregh, and I hope he got it straightened out.

> I am still of the opinion that the alpha clients shouldn't be talked about as
> much as they are here however I would be much happier if you simply include a
> "surgeon general's warning" in every thread about a non-stable client. The
> primary source for bug reports to the devs is NOT this forum. All of the
> problems with the 4.14-4.18 clients were reported within minutes or hours on
> the developer mailing list. There is way too much garbage on these message
> boards for it to be used as an effective bug reporting tool. Yes, there have
> been a few reported here but not nearly as many as have been reported through
> other channels so to view the threads as a bug reporting tool is not very
> accurate.

I think most of the message board would like to help even if just a little. Help me understand this. Are you of the opinion that our help is without worth? Or just not enough to make it viable in regards to the risks you envision?

Thanks for your efforts in this project, I will consider your position.

tony

---

crap! Someone who is actually willing to listen to "the other side" of an issue! What do I do? :)

I don't know... I might be making a bigger deal out of this than it really is but I do feel that exposing the "unwashed masses" to experimental software is like playing with fire. The alpha testing projects limit their user base for a reason. As I said, there HAVE been some useful bug reporting threads on these message boards so I suppose some good has come of the threads in question.

What I think it comes down to is that *I* won't be making any posts about pre-release stuff here. You (and others) obviously disagree with me on the subject and that is your right. As long as there is sufficient warning to casual readers I promise not to yell at you again :)

---

A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site

> crap! Someone who is actually willing to listen to "the other side" of an
> issue! What do I do? :)

Sorry, I'm old, I've learned to be patient, and that I don't always know what's best. I used to know though.... I wonder what happened...I used to know everything.
>
> I don't know... I might be making a bigger deal out of this than it really is
> but I do feel that exposing the "unwashed masses" to experimental software is
> like playing with fire. The alpha testing projects limit their user base for
> a reason. As I said, there HAVE been some useful bug reporting threads on
> these message boards so I suppose some good has come of the threads in
> question.
>
> What I think it comes down to is that *I* won't be making any posts about
> pre-release stuff here. You (and others) obviously disagree with me on the
> subject and that is your right. As long as there is sufficient warning to
> casual readers I promise not to yell at you again :)
>
You're a very gracious person.

I promise to try to warn people.

tony

---

I think what Toby meant by the poll was flawed and I dont pretend to speak for him but I agree that it was flawed in the way it was worded and what it says about anyone that would post in it.

Let me put this another way. Lets take this poll as an example of a flawed poll.

Anyone who didnt read the warning label on a piece of machinery and lost an limb/digit/etc post here that you didnt see it/understand it.
You probably wouldnt get more than 1 or 2 people to admit that. However in the order of 1,000 every year perhaps higher do.

Now if you post that poll in the lawn maintance and care professional's board you have an example that is comparable. Most people here are in the know so to speak about the clients DC in general and what not. Its the none pro none posting surfer that will see this.

Subject line: Got a fishing line tangled in my mower the other day so had to reach under there and pull it out. Of course they know that any professional would disconnect the power before doing such a thing but joe public? probably not he runs into same problem and says hey I read about that its OK to do this.

Well long post and Im sure you get my point. I personally dont think the posts are bad as such with the warnings but I can see where a person could be lead astray.
In fact I do like to see the problems that people are having with the new clients so I know what to look out for if I should need to use one of them.

---

<a href="http://www.teampicard.net"><img src="http://boinc.mundayweb.com/seti2/stats.php?userID=2205&amp;trans=off"></a>

let me start by saying that i have to agree with most everything in this thread but for the following:
> Subject line: Got a fishing line tangled in my mower the other day so had to
> reach under there and pull it out. Of course they know that any professional
> would disconnect the power before doing such a thing but joe public? probably
> not he runs into same problem and says hey I read about that its OK to do
> this.
>
see, i am firmly of the opinion that we coddle people entirely too much. if you chop your hand off because you didn't stop the mower before sticking your hands in there, you have only one person to blame.
there is some couple trying to sue wal-mart because they sold a shotgun to their 24 yr old daughter who used it to kill herself. their arguement? she had a prescription at a different walmart for an anti-psychotic. now in the US, prescriptions are CONFIDENTIAL, if they had used this info, or even had any such access to it, that would be a big problem. but these parents feel the need to place the blame well outside of where it lies.

> Well long post and Im sure you get my point. I personally dont think the posts
> are bad as such with the warnings but I can see where a person could be lead
> astray.
> In fact I do like to see the problems that people are having with the new
> clients so I know what to look out for if I should need to use one of them.
yes, i too do like the occasional update of releases and about other projects, warnings are good to the effect of "use at your risk" or einstein has asked to use xxx client, etc. of couse, to a minimum of threads.

just my 2¢

Micah

---

S@h Berkeley's Staff Friends Club

> I agree, Heck, I'm one of them. Sometimes I hate my Bob Newhart style of
> humor. The title of my post was "HMMMM...Boinc 4.19 released.....Come and get
> it". The HMMM part is indicating of my skepticism of yet another update. I
> mean, there had been 3 days of updates. It was supposed to be humorous. The
> Boinc 4.19 thing is self explanitory. The "come and get it" was a reference
> to old days when Mom (ok, my mom didn't but maybe hers did) would ring the
> dinner bell. I found it funny that everyone would once again commence the
> downloading and installing yet one more time. By this time I didn't really
> thing another "use at your own risk warning was necessary.

FWIW, releasing clients as fast as they can to the alpha team is a regular thing when Berkeley wants to get a new client out the door. Build it, give it to alpha, wait for a few bugs, fix the bugs, and start over.

It's more effective than I thought it would be. Ideally, I think we need a few days of holding between the last release and releasing to the public, but they don't pay me the big bucks to make those kinds of decisions. :-)

In response to other posts on this thread:

1) You can't keep the prerelease clients out of the hands of the public in an open source project like this. I mean, I guess you could... but why would you want to?

2) Posting to the boards about new alpha releases like that is asking for trouble. Wait for somebody to test it and say it didn't break their computer before posting, perhaps... you're confusing the Clueless n00bs.

3) Clueless n00bs who feel they were wronged: Learn to read, the download page quite clearly states which is the development (ie; not done yet) version and which is the version for public consumption.

I've suggested in the past people download an Alpha build to get around a bug or check out a new feature, but it's always with the understanding that it can break your computer... and it's always been a build I've used myself and know of other Alpha testers who used it as well.

Just use a little common sense.... even if it isn't all that common these days. :-)

---

Rob

> FWIW, releasing clients as fast as they can to the alpha team is a regular
> thing when Berkeley wants to get a new client out the door. Build it, give it
> to alpha, wait for a few bugs, fix the bugs, and start over.
>
> It's more effective than I thought it would be. Ideally, I think we need a
> few days of holding between the last release and releasing to the public, but
> they don't pay me the big bucks to make those kinds of decisions. :-)

I guess you can say I'm copying the MS playbook a little bit, once you reach ZBB( Zero Bug Bounce, all the bugs that need to be fixed for release), you freeze the branch and then only accept priority one severity one bugs for the duration of a test pass. During the process, new releases are released as needed, each new release is referred too as a dot release.

Since I can't add in additional version information due to BOINC's design, I just increment the minor version util we reach our target. What some people loose site of is, it was the 4.13 release with a few additional fixes, so after 4.14 was relaesed and tested, you can say that the test pass began and we just needed to shore up a few additional issues. Keep in mind though, 4.13 had already been released to the public, and two of the bug fixes we took for 4.14 had already been in alpha for a month or two.

Each additional release didn't require a restart of the full test pass, just a few additional tests around the bug fix area.

Changing the minor version and rebuilding frequently has an additional advantage, it reduces confusion about what bugs are fixed when, and keeps everyone in sync with what is going on. Releasing private builds, or re-releasing with the same build number only adds confusion to the process.

---

----- Rom
BOINC Development Team, U.C. Berkeley
My Blog

Posting to the boards about new alpha releases like that is asking for trouble.
More like "announcing" instead of "asking", but I agree 99.9% with what you said next:

Wait for somebody to test it and say it didn't break their computer before posting, perhaps... you're confusing the Clueless n00bs.
I'm no n00b, but when you're talking about six different projects, at least nine BOINC client versions are mentioned (and who knows how many versions of the projects' executeables), and top it off with Win/x86, Lin/x86, Mac/ppc... I needed a score-card.

In addition to the version madness, there were posts that had claimed that the admins wanted users to upgrade BOINC to 4.16 ASAP (I believe it was attributed to Rom). Not only didn't I find the BOINC 4.16 Mac/ppc, I didn't even find the source code! So in essence, people were reacting to a non-authoritative poster asking the users to do something partly impossible!

Like any other cruncher here, like any other programmer anywhere, I'm very enthusiastic when a project goes into alpha. But please don't drive the users insane: (1) Keep the alpha chatter in an alpha thread, (2) stick to one app/version at a time, (3) what other projects do is their own problem (Keep it in a labeled thread, like "E@H Thread" or something...), and (4) let the admins make the call as to when and what to upgrade to.

2&cent;

---

Couldn't have said it better!

> Like any other cruncher here, like any other programmer anywhere, I'm very
> enthusiastic when a project goes into alpha. But please don't drive
> the users insane: (1) Keep the alpha chatter in an alpha thread,
> (2) stick to one app/version at a time, (3) what other projects
> do is their own problem (Keep it in a labeled thread, like "E@H Thread" or
> something...), and (4) let the admins make the call as to when and what
> to upgrade to.
>
> 2¢
>

---

Glad to know that I'm not the only crazy guy here! :-)

---

> I guess you can say I'm copying the MS playbook a little bit, once you reach
> ZBB( Zero Bug Bounce, all the bugs that need to be fixed for release), you
> freeze the branch and then only accept priority one severity one bugs for the
> duration of a test pass. During the process, new releases are released as
> needed, each new release is referred too as a dot release.

This is roughly the strategy I did a a company that shall remain nameless, but, I woiuld freeze the baseline for features, usually 2-4 weeks before a delivery while it was in testing and we were in the process of doing all of the other things that needed to be done in the delivery process.

All of the testing that was done was to establish what we had gotten done and to look at behaviors that caused "death". Those were the only fixes that were done until after delivery. At that point we would open up again to add features and fix all of the non-death issues discovered in testing.

A sad reality right now is that the technology to create comprehensive coverage with testing is not yet available. So, you bite the bullet and ship ...

For myself, I can't see anything that could be changed that would make a substantial differrence in the results. Granted, I was not that thrilled to make daily updates to my 6 machines, but the installs do work and even though I was not seeing the problems others were it was part of what I signed up for when I decided to BOINC, and again after I signed up for multiple projects.

---

very well said NA and Paul!
i too have no problem 'testing' software, i don't have the know-how to know what caued it to break (if it does) but can provide the setup and error code/symptoms.
i personally see BOINC in general as being 'at your own risk.' that is, i didn't buy the software and i am not being paid to run it - i want to help the project and science and am donating my PCs and electricity. i don't want to be on the bleeding edge, but will gladly update to it if a developer specifically asks me to for some reason. you always need to check where your information is coming from.

---

S@h Berkeley's Staff Friends Club

> very well said NA and Paul!
> i too have no problem 'testing' software, i don't have the know-how to know
> what caued it to break (if it does) but can provide the setup and error
> code/symptoms.

We are in an adventure. I guess I got fired up, lo these many years ago, in high school. I don't have the temprement to *DO* research (or selling) but I like the feeling of exploring new worlds.

I can do computers, and I *DO* know what happens and why when they break ... any way ...

Thank you for the complement. :)

---

> Changing the minor version and rebuilding frequently has an additional
> advantage, it reduces confusion about what bugs are fixed when, and keeps
> everyone in sync with what is going on. Releasing private builds, or
> re-releasing with the same build number only adds confusion to the process.

Indeed - I like the strategy. You don't see it frequently in open source software at quite this degree.

The only change I'd make to it is I would reset the clock with each release, just to play it on the safe side. I realize in this particular case there were other concerns at hand, though.

---

Rob