Licensing

BZR

on the wikia - how to get started with bzr (ronald and mark worked on it)
main dev branch, only 2 people who have access to it (Brian is one of them). The main branch is called "trunk"
Brian pulls stuff, tests it daily.
Jay, Monty and Stewart have been taking other people's branches, merge it with their branch, and then push it to Brian for him to merge that tree into the trunk
Brian's vision is that the test czar will be like a Jay, Monty or Stewart; except never committing anything else, just the test subtree. When you commit, commit on one idea/"unit of work" at a time.

on the wiki - Why should we care about this when it sounds like sqlite?
answers in launchpad, or use a blueprint and mark it informational.
drizzle doc mailing list?
explaining WHY we lack server-side prepared statements (it's got what it always had, it was disabled in the server), but have client-side prepared statements.
has innodb, it has transactions

Need for an asynchronous client
Import the innodb plugin into the tree
Dependencies in client libraries are bad ideas
Ifdef libraries is OK, ifdef structures is bad.
Remove tabs except in the makefile.am (only the first one)
put on the wiki - the code style vim.rc (BSD code style with 2 spaces as tabs) hg.tangent.org/vim.rc

We're not using MySQL's (EXPLAIN is nondeterministic, that's a big problem). In test cases, every test case is a large file with 10s of 100s of SQL statements, if one dies, the whole test case has been disabled, so it's silly.
Maybe we should use a testing protocol like what perl uses (TAP, testanything.org) which reports on granularity. Assume everyone has a working Perl.
Basically whoever writes a good test system, it will get in.
do we embed the ?dpn? (Ronald)
Move to more like a unit test scenario, test/assertions/results in one file, set up/test/tear down methods, one tests config, another tests sql, third category is testing all the OS commands and options. wrap a few syntaxes around that, take error handling and concurrency testing into that. It's English-like, Ronald proposes translating to lua (as one option due to leverage of dpm Proxy). (small dsl (domain-specific language) around test libraries?) (Brian worries about lua because it's not installed everywhere)
Testing is a high priority right now.
Test harness, someone will need to be responsible other than Brian

listen to people
write readable code
anything that Brian can hand off, he will
set of people Brian will try to pull trees from daily, these people will show up a lot and be willing to take on other people's patches. Idea is that trees will already be tested some (buildbot will solve a lot of the non-compile issues)
it's OK to make a mistake, Brian believes in politeness, everyone makes mistakes (even Brian).

Keep the code clean -- things should compile without warnings (or errors). Right now compilation warnings are turned into errors, so warnings aren't compiled in.
Code style -- was in blueprint, a stub on wikia now. (don't return ints unless you want the size of the int, if you want 0 or 1, return boolean, make enums if you want a few numeric values).

Strip the server down, almost done with it.
SQL modes removed, flags removed, VIEWs removed, Brian likes VIEWs but it's going to be done right if it's going to be put back in (rewrite engine, which isn't how MySQL does it now).
added plugin points for UDFs, logging, ACLs (will bump to PAM or LDAP)
Current MySQL is going to a loosely designed plugin mode where things aren't transparent. Brian's not a fan.
Drizzle won't be treated as both C or C++
Removing ZEROFILL and INT(x).
Fewer primitives now, more advanced types later.
Brian wants patches to go into bzr, not e-mailed.

Site generously hosted by SoftLayer Technologies