Hi Guys

Dojo is really a wonderful and unique toolkit, and I am really happy working with it.And of course the success of it is from my selfish interest very important.
I have some procedural questions that probably one of you may have the time and interest of answer me (I will be very grateful).

All my questions are related to the Nightly Builds (not to the released versions).

[1] I noticed that in the last month or month +1/2 some critical bugs that made the Grid practically impossible to use were introduced, some of the bugs are very easy reproducible because breaks the tests (given in the build itself); is any check by running the tests done, before some piece of code is released ?, in order to assure that a Know Bug is NOT being replaced by a group of several new and unknown bugs?
My very subjective impression is that from the quality point of view, the Grid is diverging and not converging to a stable configuration.

[2] What is the policy of choosing the bugs to be corrected? Ticket #6825 defines a complete crashing (in lot of tests programs) in Firefox 2. For me (humble opinion) ,the correction of any other bug before this, is like giving Aspirin to a dead person.

[3] Ticket #6751 and the closed #5469 defines a scrolling in grid (when container is less than grid size) is Critical for IE7 browser. The grid scrolls so the choosing of the row or cell will never be the one the user intended. In other words, you choose not the row or cell you intended, you choose one below.

[4] Ticket #6750. You receive always in Firefox 2 two onClickCell and onClickRow events instead of one. For example if you expect to do a specific action when a cell or row is clicked, this action will be done twice, because two events are received !.
This is not a critical problem for Idempotent actions, but sadly not all the actions have those characteristics.

Please see these lines as truly and constructive criticism coming from real concern, the investment we done here in using Dojo is so much, that any negative impact in this wonderful toolkit will be in consequence bad for us, too.

We see as a contribution to this project, opening tickets after we verify that the problem is not coming from one of the two following sources: [A] our miss usage [B] new legal functionality, changes in API, etc.
In addition we only open a Ticket after [1] We can find a test program that replicates the problem [2] We can write a test case to prove the problem.
We are investing hours each days to assure the above.

Working with the Nightly Builds assure (In Our subjective Opinion) that we contribute in some small extent to the QA. of the next version, (good for us/good for everyone)

If there is any other information, style of problem definition, etc that we can do or follow, to help you more, we of course will be happy to follow those rules.

thanks very much in advance for any reply.

Eduardo