RE: Status update?

Mark Matthews writes:
> I've also finally been given the go-ahead to hire one more
> developer to work on ODBC in tandem with Peter.

Sounds like good news, congratulations!


> What we could really use from the community is the following:
> (1) Testing of 5.0 releases,

I'll sum up our situation, perhaps you can use it as input
(perhaps not).

The reasons we use Connector/ODBC are:

 1) It's been around the longest and should thus be the stablest.

 2) A Windows ODBC driver is a relatively small component compared
    to a full-fledged DOTNET v2 data provider.  Leaving most of the
    DOTNET data provider implementation to Microsoft and their
    System.Data.Odbc wrapper and instead concentrating on the ODBC
    part seemed like the quickest way to achieve a stable connector.

If I had time to fiddle with alpha software I could also play with
Connector/NET.  Connector/NET happens to have other things going for it:

 a) It's easy to build.

 b) Changes are documented in the commit log, so if I find a regression,
    I can go look for related changes.

 c) Bugfixes are documented in the commit log, so if I want to know when
    a particular bug was fixed, I can look it up in the log.

 d) Every commit has a log message.  If I look at changes for the last
    week, I instantly know whether there is something worth testing or
    if it's all whitespace fixes, and which areas I should concentrate
    my testing on.

Looking objectively at the situation as a DOTNET user of Connector/ODBC,
the primary thing that Connector/ODBC should have going for it is that
the GA release should be free of major bugs.  I think you guys have
failed to deliver that, if it was indeed ever a goal for you.

With stability out of the picture, we can get everything else we
need from Connector/NET.  With the Connector/NET development process
being friendlier towards users (testers) as described above, it looks
like a better place to spend time alpha testing.

I think that sums up our situation.


> we didn't get a lot of people trying out the first alpha of 5.0,
> so we got basically zero feedback.

Fixing a), b), c) and d) above would be enough incentive
for me personally to give a hand with alpha testing.

Constructive (or so I hope) suggestions for things
that you guys could try to attract testers:

a)
Release often.  Don't expect people to come running when you happen to
want something tested, instead try to give users the possibility of
testing when they want.  People generally want to help test, if only
it's not too much work.  Hand them a release whenever you've fixed
something, by setting up a machine to do a nigthly build.  Stuff the
version number that the build machine gets when it runs "svn update/
checkout" into the source code so there's an easy way for people to
report their version number.  Make sure that old versions of PDB files
are available so users can easily report problems with symbols resolved.
Make sure that old versions of DLL files are available so users can
perform regression testing without setting up a build environment.

b), c) and d)
Document your changes.  It takes 5 minutes to write a good log message,
but it takes one user half an hour to figure out what a change does
without a log message.  Multiply that half hour by the number of commits
a day and the number of users that would like to test alpha releases.
Writing good log messages shows your users some courtesy by not wasting
their time.


> I'd like to ask the community what bugs are most painful for them to
> deal with (David I have your list already).

Since you're not on my payroll I don't expect you to pay any attention
to my list of priorities.


> What we promise in return:
...
> * Much more interaction with the community at large (it's actually a
> quarterly goal for the entire team).

A lofty and most welcome goal, but not very concrete..

I'd like to see a promise from you guys to respond to problem reports
within a given timeframe.  I realize that support customers should get
much better service than community members, so the interval should be
large - say, a month from a problem is reported to you giving *some*
feedback.

By "feedback", I don't mean "fix".  I just mean any status, could be:
- "yeah OK, we'll take a look at that when time permits" or
- "we're probably never going to look into that" or
- "you'll need to do more testing yourself" or
- "please make a more concise problem description" or
- "bug in another component; report <here> instead"... whatever.
Could also be something more uplifting ;-), but that's by
no means a requirement.


> Feel free to yell at me if you
> don't see us on this mailing list or the forums enough.

Okey dokey.  See this bug:
http://bugs.mysql.com/5225

Half a year ago, two people asked for a status.  Since then, I've
personally asked the lead on the bug for a status - twice.

There's been no communication from you guys whatsoever.
IMHO this would be a fine place to start cleaning up your act ;-).


Lastly, kudos on the way you guys handled fx.:
http://bugs.mysql.com/18755

A timely response and (some) communication regarding
the root cause of the problem.  I'm impressed!


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe:    http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@xxxxxxxxxxx