On the 'Tasks' tab, grid view. If you click on 'Report Deadline' to sort by that field, the sort does not take AM/PM into account. This leads to 6:14PM sorting before 8:42AM.

Boinc Manager 6.2.19.

It's been reported before - message 20137 - but Jord was waiting for confirmation before passing it on to the developers.

Thank you for supplying the confirmation, and also confirming that the problem still exists on the latest v6.2.19 recommended release.

It's reported to be fixed in 6.3.x, can somebody check? (although 6.4 might have brought the problem back; please test this too)

See [trac]ticket:116[/trac] and [trac]ticket:427[/trac]

---

...
See [trac]ticket:116[/trac] and [trac]ticket:427[/trac]

Perhaps you wanted to say "See [trac]ticket:166[/trac] and [trac]ticket:427[/trac]"?

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

It's reported to be fixed in 6.3.x, can somebody check? (although 6.4 might have brought the problem back; please test this too)

OT: The 6.3.x line contained a lot of fixes, I wonder whether the bugs will have to be discovered and fixed once more, or the known fixes (and new functionality too?) (back/forth)ported to the 6.4.x line? I believe Rom have not mentioned this point...

Peter

I think Rom reverted to 6.2 + CUDA code to get the first 6.4 out the door sooner.
Most of the minor bug fixes and other changes included in 6.3 will may have to wait for 6.5 for testing and put in the 6.6 release.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

I think Rom reverted to 6.2 + CUDA code to get the first 6.4 out the door sooner.
Most of the minor bug fixes and other changes included in 6.3 will may have to wait for 6.5 for testing and put in the 6.6 release.

That's how I understand the situation.

---

Kathryn :o)

Just why is v6.4.x release more important than bugfixes?

Trac [trac]#166[/trac] is over 2 years old, and patch code was added to it in April 2007.

Now we're told that it's going to wait until v6.6.x. Timeline?

Will bugfixes (in general, not just this particular one) have to take a back seat once again when the next bright idea comes along? I personally have reports [trac]#366[/trac], [trac]#525[/trac], and [trac]#588[/trac] still open. I regard [trac]#136[/trac] as a still-present bug, even though it was closed (on the basis of a false understanding, the first time round, although the second closure matches reality more closely).

The way I understand the thinking is that the to-do list is very long and priorities need to be set. Minor bugs that can be easily fixed are taken care of on the fly. Others that are not roadblock for the majority just have to wait.

CUDA represent a whole new avenue of processing and is required by a new project therefor needs to get in the wild as soon as possible to see what problems it might create on a larger assortment of systems. Other projects may also be able to take advantage of this new processing power.

There are other major changes that are also waiting in the wings. Facilitating true multithreaded application is one that I know of. I also understand that AMD as contacted DR. A about providing assistance in using the ATI chip set to crunch.

When you have a large stack of jobs on your desk, you have to choose which need to be done first and which one can or must wait a little longer. Everyone has his own idea about what order thing should be done. Also, don't forget there are only a couple of bodies to get it all done.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

... get in the wild as soon as possible to see what problems it might create on a larger assortment of systems ...

Not to mention a larger assortment of projects, many of whom haven't yet recovered from the v6.2 graphics compatibility change.

You've got the BOINC testing paradigm described to a T.

... get in the wild as soon as possible to see what problems it might create on a larger assortment of systems ...

Not to mention a larger assortment of projects, many of whom haven't yet recovered from the v6.2 graphics compatibility change.

You've got the BOINC testing paradigm described to a T.

Unfortunately, the Boinc alpha volunteer test group is extremely small, and doesn't come close to be representative of the thousands of system configurations in the Boinc community. The obvious problems get taken care of by Alpha testers, but on more than one occasion Boinc has had to remove an official release within hours of being posted for distribution. That is and will likely continue to be one of the biggest problems in the Boinc development. Not enough people to program the software and not enough people testing it.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

But enough people complaining about it. ;-)

---

...
See [trac]ticket:116[/trac] and [trac]ticket:427[/trac]

Perhaps you wanted to say "See [trac]ticket:166[/trac] and [trac]ticket:427[/trac]"?

Argh, yes.

---