[Maria-developers] Pushing/merging sample my.cnf
All, I've created my trunk on launchpad for MariaDB, and am ready to make some updates to the sample my.cnf file(s) packaged with MariaDB. I have a few questions regarding how to proceed: 1. I've seen work log creation and assignment in MariaDB developer mailing list. Is work log creation necessary for changes like this, where no C/C++ source code is touched? If yes, any guidelines will be appreciated; 2. As this is more packaging related, what are the testing requirement? 3. What about peer review? I've blogged this and also just sent another email for more input. 4. After I make the change on my machine, build it, and push the changes back to Lauchpad, I will do a merge request. 5. Anything else? Comments/suggestions? Thanks, Haidong "Alex" Ji
Hi, Haidong! On Mar 18, Haidong Ji wrote:
All,
I've created my trunk on launchpad for MariaDB, and am ready to make some updates to the sample my.cnf file(s) packaged with MariaDB. I have a few questions regarding how to proceed:
1. I've seen work log creation and assignment in MariaDB developer mailing list. Is work log creation necessary for changes like this, where no C/C++ source code is touched? If yes, any guidelines will be appreciated;
No, it's not necessary.
2. As this is more packaging related, what are the testing requirement?
that mariadb can be started with your my.cnf file :) At the moment, we don't test the default my.cnf in our test suite, and I don't want to require you to change that (but you'd like you - you're welcome, I can explain how). So, just test manually that your config is correct.
3. What about peer review? I've blogged this and also just sent another email for more input.
good
4. After I make the change on my machine, build it, and push the changes back to Lauchpad, I will do a merge request.
right.
5. Anything else? Comments/suggestions?
question. should a default my.cnf work with all mariadb configurations? I mean, builds without innodb/xtradb for example. Which boils down to - should you prefix all innodb options with "loose"? It'll make my.cnf more universally useful, but slightly more confusing too. Regards, Sergei
Thanks Sergei!
question.
should a default my.cnf work with all mariadb configurations? I mean, builds without innodb/xtradb for example. Which boils down to - should you prefix all innodb options with "loose"? It'll make my.cnf more universally useful, but slightly more confusing too.
I am of the minimalist opinion. That is, I am inclined to take out all engine-specific settings. But on top of the sample file, we will just say please follow this URL where we have additional sample files where the knowledge is crowd-sourced. But that is just my opinion. Haidong Ji
Hi, Haidong! On Mar 25, Haidong Ji wrote:
Thanks Sergei!
question.
should a default my.cnf work with all mariadb configurations? I mean, builds without innodb/xtradb for example. Which boils down to - should you prefix all innodb options with "loose"? It'll make my.cnf more universally useful, but slightly more confusing too.
I am of the minimalist opinion. That is, I am inclined to take out all engine-specific settings. But on top of the sample file, we will just say please follow this URL where we have additional sample files where the knowledge is crowd-sourced. But that is just my opinion.
I believe, I've heard that some innodb options are quite important to have set in my.cnf, if we want to have good out of the box performance. That is, minimalist is fine. But will you be able to reach your goals (e.g. "benefit as many people as possible") if you leave out all engine specific settings? Regards, Sergei
Sergei,
That is, minimalist is fine. But will you be able to reach your goals (e.g. "benefit as many people as possible") if you leave out all engine specific settings?
You are absolutely correct. Some bare minimum, best practice MyISAM and InnoDB should be included, although there are endless definitions of "bare minimum and best practices". I guess I didn't mean to suggest to not include any engine-specific settings whatsoever. Thanks, Haidong Ji
participants (2)
-
Haidong Ji
-
Sergei Golubchik