- developers - lists.mariadb.org

[Maria-developers] Closing bugs as Incomplete/Cannot reproduce requires FixVersion?
by Sergey Petrunia 23 Aug '14

23 Aug '14

Hi Serg, (writing to you because I think it was you who set Jira's rules for Fix Version field). I'm trying to close MDEV-6032 as "Incomplete" ("Cannot reproduce" would also work). This resolution is meant to say that the issue is not really resolved. And Jira's "Close Issue" dialog gives me this error: Field Fix Version/s with actual value does not match regular expression \[([0-9]+\.[0-9]+\.[0-9]+.*|N/A)\] I think it doesn't make sense. I even think that "Fix Version" must be empty for bugs that are closed with resolution other than "Fixed" or "Duplicate". Do you agree with this reasoning? If yes, is it possible to fix Jira to follow this logic? BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] Learning about MariaDB
by Kavneet Kaur 22 Aug '14

22 Aug '14

Hi! I am highly interested in subject of database. I am also interested in becoming a research developer. Worked on MS SQL. Want to try MariaDB. May I get the guidance about this product as i'm totally new to it. Is there any specific way to begin?

1 0

[Maria-developers] [GSoC] Pencils down
by sriram patil 21 Aug '14

21 Aug '14

Hi All, Following is the link to my pencils down blog post. You can go through it even if you have not followed my blog posts before. http://goo.gl/DqBgDe Thanks a lot for all your feedback and suggestions. Sriram.

3 3

[Maria-developers] [GSOC2014] UseServerPrepStmts - Connector/J
by Puneet Dewan 20 Aug '14

20 Aug '14

Hi Everyone, I have pushed the code and it can be found on the following link: https://code.launchpad.net/~team-java-connector/mariadb-java-client/mariadb… Thanks for the support. :) Please review and give suggestions. Regards Puneet.

1 0

Re: [Maria-developers] [GSoC] Optimize mysql-test-runs - Results of new strategy
by Pablo Estrada 19 Aug '14

19 Aug '14

Hello Elena and all, First, addressing the previous email: Looking at the dump, I see it can also happen that the dump contains > several records for a pair platform/bbnum. I am not sure why it happens, I > think it shouldn't, might be a bug in buildbot and/or configuration, or > environmental problems. Anyway, due to the way we store output files, they > can well override each other in this case, thus for several platform/bbnum > record you will have only one file. I suppose that's what was hard to > resolve, sorry about that. > No worries ; ). There are several cases where platform and build number are the same. The system just names the files as follows: <platform>_<build_id>-log-test_1-stdio <platform>_<build_id>-log-test_2-stdio ..... <platform>_<build_id>-log-test_5-stdio These files seem to correspond temporarily with the test runs (*test_1-stdio) belongs to the first test_run of the same plt-bnum, and so on. Unfortunately, there are some cases where there are more test_runs on the dump than files available, and this means that it's impossible to be sure which file belongs to which test_run exactly. > You should consider skipped tests, at least for now. Your logic that they > are skipped because they can't be run is generally correct; unfortunately, > MTR first produces the *full* list of tests to run, and determines whether > a test can be run or not on a later stage, when it starts running the > tests. Your tool will receive the initial test list, and I'm not sure it's > realistic to re-write MTR so that it takes into account limitations that > cause skipping tests before creating the list. > I see. Okay then, duly noted. Possibly it's better to skip a test run altogether if there is no input > list for it; it would be definitely the best if there were 5K (or whatever > slice you are currently using) of continuous test runs with input lists; if > it so happens that there are lists for some branches but not others, you > can skip the branch entirely. > This doesn't seem like a good option. Recall drops seriously, and the test_runs that have a corresponding file don't seem to have a special pattern, and tend to have long spaces between them, so the information becomes irrelevant, and seemingly, not useful. > The core module should take as parameters > - list of tests to choose from, > - size of the running set (%), > - branch/platform (if we use them in the end), > and produce a new list of tests of the size of the running set. > > The wrapper module should > - read the list of tests from the outside world (for now, from a file), > - receive branch/platform as command-line options, > - have the running set size set as an easily changeable constant or as a > configuration parameter, > > and return the list of tests -- lets say for now, in the form of <test > suite>.<test name>, blank-separated, e.g. > main.select innondb.create-index ... > >> >> I am almost done 'translating' the code into a solution that divides it in 'core' and 'wrapper'. There are a few bugs that I still haven't figured out, but I believe I can iron those out pretty soon. I will also incorporate the percentage rather than fixed running_set. Now, regarding the state of the project (and the recall numbers that I am able to achieve so far), here are some observations: - Unfortunately, I am running out of ideas to try to improve recall. I tried tuning some parameters, giving more weight to ones or others, etc. I still wasn't able to push recall beyond ~87% on the strategy that uses file correlations. For what I've seen, some failures are just extremely hard to predict. - The strategy that uses only a weighted average of the failure frequency achieves a higher recall, but for a shorter time. The recall decays quickly afterwards. I may try to add some file-correlations to this strategy, to see if the recall can be sustained for a longer term. - There is one problem that I see regarding the data and the potential real-world implementation of the program: By verifying the recall with the historical data, we run the possibility of 'expecting' overfitting... so the results regarding the errors found when comparing to the historical data, and the results that could have been obtained by a real-world implementation are potentially different. A possible way to address that issue would require modifying the buildbot to gather more data over a longer term. So having said that, I am looking for some advice in the following regards: - I will try to take a step back from the new strategy, and see how I can adapt the original strategy to prevent the recall function from declining so sharply with time. - I will also spend some time keeping a codebase that adjusts better to the model that we need for the implementation. I will upload code soon. All suggestions are welcome. - Nonetheless, I feel that more data would allow to improve the algorithm greatly. Is it possible to prepare logging into the buildbot that would allow for more precise data collection? A slower, more iterative process, working closer with the buildbot and doing more detailed data collection might deliver better results. (I understand that this would probably influence the time-scope of the project) Let me know what you think about my suggestions. Regards Pablo

2 22

[Maria-developers] [GSoC] Week Twelve!
by sriram patil 14 Aug '14

14 Aug '14

Hi All, Following is the link to my twelfth weeks blog post. http://goo.gl/Zkr86e Suggestions and/or reviews are welcome! Thanks, Sriram

3 2

[Maria-developers] Fwd: I have a replication patch, please accept it.
by Colin Charles 12 Aug '14

12 Aug '14

Xu Liang, the best place to post it is maria-developers I've done that via a FWD -- Kristian, what do you think? Begin forwarded message: > From: "Xu,Liang(OP)" <xuliang02(a)baidu.com> > Subject: I have a replication patch,please accept it. > Date: 6 August 2014 15:31:27 GMT+8 > To: "kb-admins(a)askmonty.org" <kb-admins(a)askmonty.org> > > http://bugs.mysql.com/bug.php?id=73479 > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Baidu DBA 徐良 > 分机：86912826 > 手机：18689220441 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles

1 0

[Maria-developers] MariaDB 10.0.13 Release Prep
by Daniel Bartholomew 11 Aug '14

11 Aug '14

I've begun the prep work for the MariaDB 10.0.13 release. Draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-10013-release-notes/ - https://mariadb.com/kb/en/mariadb-10013-changelog/ A big thanks to those that have already contributed content! As always, please let me know ASAP if anything else needs to be added/changed/etc..., or jump in and do it yourself. Thanks! -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

1 0

[Maria-developers] innodb-buffer-pool-instances confusion
by Daniel Bartholomew 07 Aug '14

07 Aug '14

I was chatting with some folks on IRC and someone pointed this out to me. On the "Upgrading From MariaDB 5.5 to MariaDB 10.0" page, it says that the new default value for innodb-buffer-pool-instances is '0': https://mariadb.com/kb/en/upgrading-from-mariadb-55-to-mariadb-100/ And when I run the following, it says the default is indeed '0': mysqld --no-defaults --verbose --help | grep innodb-buffer-pool-instances ... innodb-buffer-pool-instances 0 But when I'm in the client, I get the following: MariaDB [(none)]> select @@innodb_buffer_pool_instances; +--------------------------------+ | @@innodb_buffer_pool_instances | +--------------------------------+ | 8 | +--------------------------------+ So when innodb-buffer-pool-instances is set to '0', does that mean the actual value is dynamic or calculated in some way based on my other settings? Just trying to understand what's going on, and once I do, use it to update the XtraDB/InnoDB buffer-pool page (which doesn't appear to have been updated for 10.0). https://mariadb.com/kb/en/xtradbinnodb-buffer-pool/ Thanks! -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

4 3

[Maria-developers] CONNECT system variables
by Ian Gilfillan 07 Aug '14

07 Aug '14

Hi I am trying to document the CONNECT system variables at https://mariadb.com/kb/en/mariadb/documentation/storage-engines/connect/con… but I can't seem to find much documentation in the code. I managed to put something together from Olivier's notes in JIRA for some of them, but can anyone help fill in the gaps and send me details on the other variables? thanks, ian

1 0