Who is working on MySQL 5.7?

First I find out the first commit that is in 5.7 that isn’t in 5.6 (using bzr missing) and then look at the authors of all of those commits. Measuring the number of commits is a really poor metric as it does not measure the complexity of the code committed, and if your workflow is to revise a patchset before committing, you get much fewer commits than if you commit 10 times a day.

There are a good number of people who are committing a lot of code to the latest MySQL development tree. (Sorry for the annoying layout of “count. number-of-commits name”)

  1. 1022 Magnus Blaudd
  2. 723 Jonas Oreland
  3. 329 Marko Mäkelä
  4. 286 Krunal Bauskar
  5. 230 Tor Didriksen
  6. 218 John David Duncan
  7. 205 Vasil Dimov
  8. 197 Sunny Bains
  9. 166 Ole John Aske
  10. 141 Marc Alff
  11. 141 Frazer Clement
  12. 140 Jimmy Yang
  13. 131 Joerg Bruehe
  14. 129 Jon Olav Hauglid
  15. 125 Annamalai Gurusami
  16. 106 Martin Skold
  17. 104 Nuno Carvalho
  18. 103 Georgi Kodinov
  19. 102 Pekka Nousiainen

There’s also a good number who have 50-100 commits:

  1. 99 Mauritz Sundell
  2. 97 Bjorn Munch
  3. 92 Craig L Russell
  4. 85 Andrei Elkin
  5. 81 Mattias Jonsson
  6. 73 Nirbhay Choubey
  7. 71 Roy Lyseng
  8. 68 Kevin Lewis
  9. 66 Rohit Kalhans
  10. 65 Guilhem Bichot
  11. 61 Sayantan Dutta
  12. 59 Akhila Maddukuri
  13. 58 Jorgen Loland
  14. 57 Martin Zaun
  15. 56 Harin Vadodaria
  16. 55 Inaam Rana
  17. 53 Venkatesh Duggirala
  18. 53 Venkata Sidagam
  19. 52 Gleb Shchepa
  20. 51 Norvald H. Ryeng
  21. 51 Jan Wedvik
  22. 50 Tatjana Azundris Nuernberg

And there’s even more with less than 50:

  1. 49 Manish Kumar
  2. 49 Alexander Barkov
  3. 48 Shivji Kumar Jha
  4. 48 Martin Hansson
  5. 42 Maitrayi Sabaratnam
  6. 40 Satya Bodapati
  7. 39 Horst Hunger
  8. 38 Neeraj Bisht
  9. 34 Yasufumi Kinoshita
  10. 34 prabakaran thirumalai
  11. 34 Kristofer Pettersson
  12. 33 Evgeny Potemkin
  13. 33 Dmitry Lenev
  14. 33 Chaithra Gopalareddy
  15. 33 Alexander Nozdrin
  16. 31 Hemant Kumar
  17. 31 Allen lai
  18. 31 Aditya A
  19. 30 Nisha Gopalakrishnan
  20. 30 Anirudh Mangipudi
  21. 29 Tanjot Uppal
  22. 28 Christopher Powers
  23. 27 Sujatha Sivakumar
  24. 27 Ashish Agarwal
  25. 25 Olav Sandstaa
  26. 25 Mayank Prasad
  27. 24 Anitha Gopi
  28. 24 Ahmad Abdullateef
  29. 23 Hery Ramilison
  30. 22 Vamsikrishna Bhagi
  31. 22 Praveenkumar Hulakund
  32. 22 Pedro Gomes
  33. 20 Sergey Glukhov
  34. 20 Libing Song
  35. 19 Vinay Fisrekar
  36. 19 Harin Vadodaria
  37. 18 Raghav Kapoor
  38. 18 Luis Soares
  39. 18 Gopal Shankar
  40. 18 Astha Pareek
  41. 17 viswanatham gudipati
  42. 17 Thayumanavar
  43. 17 Ramil Kalimullin
  44. 16 Oystein Grovlen
  45. 15 Dmitry Shulga
  46. 15 Amit Bhattacharya
  47. 15 Akhil Mohan
  48. 14 Ravinder Thakur
  49. 14 Kent Boortz
  50. 13 Bernd Ocklin
  51. 12 Bill Qu
  52. 11 Shaohua Wang
  53. 10 Sven Sandberg

There’s also a good number with fewer than 10 (31 names actually), which is encouraging as it means that this means it’s likely people who are not involved every day in development of new code (maybe QA, build etc) which probably means that (at least internally) contributing code isn’t really a big problem (and as I’ve shown previously, the barriers to external contributions between Oracle MySQL and MariaDB appear to result in roughly the same amount of code from people outside those companies).

There are 125 names here in total, with 19 having over 100 commits, 22 with 50-100 commits, another 53 with 10-50 commits and 31 with <10. So it’s possible to say that there are at least 125 people at Oracle working on MySQL – and I know there are awesome people who are missing from this list as their work doesn’t result in committing code directly to the tree.

Who is working on MariaDB 10.0?

There was some suggestion after my previous post (Who works on MariaDB and MySQL?) that I look at MariaDB 10.0 – so I have. My working was very simple, in a current MariaDB 10.0 BZR tree (somewhat beyond 10.0.3), I ran the following command:

bzr log -n0 -rtag:mariadb-10.0.0..|egrep '(author|committer): '| \
  sed -e 's/^\s*//; s/committer: //; s/author: //'| \
  sort -u|grep -iv oracle

 

MariaDB foundation/MontyProgram/SkySQL:

  1. Alexander Barkov
  2. Alexey Botchkov
  3. Daniel Bartholomew
  4. Elena Stepanova
  5. Igor Babaev
  6. Jani Tolonen
  7. knielsen
  8. Michael Widenius
  9. sanja
  10. Sergei Golubchik
  11. Sergey Petrunya
  12. Sergey Vojtovich
  13. timour
  14. Vladislav Vaintroub

Elsewhere:

  1. Kentoku SHIBA (4 commits)
  2. Lixun Peng (1 commit)
  3. Olivier Bertrand (212 commits)

From Oracle (i.e. revisions merged from Oracle MySQL):

  • 81 names (which I won’t list here as 81 is a lot)

The results are no different if you go back to the first revision that is different between MariaDB 5.5 and 10.0 (found using bzr missing). Even when grepping through the bzr log for things such as “patch by”, “contribution” or “originally” I can only find 1 or two more names as original authors for patches (about the same as I can for patches going into the Oracle tree).

Please point me to revisions (revid is best way) that come from outside contributors as then I really can update this to show that there’s a larger developer community.

The current development version of Drizzle (7.2) has just as many contributors as the MariaDB development version (10.0) – although Drizzle does have fewer commits.

nanomysql – tiny MySQL client lib

I recently got pointed towards https://github.com/shodanium/nanomysql/ which is a tiny (less than 400 lines of C++) MySQL client library which is GPL licensed.

If you need to link into non-GPL compatible code, there is the (slightly larger and full featured) libdrizzle library. But if you want something *tiny* and are okay with GPL, then nanomysql may be something to look at.

Who works on MariaDB and MySQL?

Looking at the committers/authors of patches in the bzr tree for MariaDB 5.5.31.

Non Oracle Contributors:

  1. Alexander Barkov
  2. Alexey Botchkov
  3. Elena Stepanova
  4. Igor Babaev
  5. knielsen
  6. Michael Widenius
  7. sanja
  8. Sergei Golubchik
  9. Sergey Petrunya
  10. timour
  11. Vladislav Vaintroub

Oracle (as they pull Oracle changes):

  1. Aditya A
  2. Akhila Maddukuri
  3. Alexander Nozdrin
  4. Anirudh Mangipudi
  5. Annamalai Gurusami
  6. Astha Pareek
  7. Balasubramanian Kandasamy
  8. Chaithra Gopalareddy
  9. Daniel Fischer
  10. Gleb Shchepa
  11. Harin Vadodaria
  12. Hery Ramilison
  13. Igor Solodovnikov
  14. Inaam Rana
  15. Jon Olav Hauglid
  16. kevin.lewis
  17. Krunal Bauskar
  18. Marc Alff
  19. Marko Mäkelä
  20. Mattias Jonsson
  21. Murthy Narkedimilli
  22. Neeraj Bisht
  23. Nisha Gopalakrishnan
  24. Nuno Carvalho
  25. Olav Sandstaa
  26. Pedro Gomes
  27. prabakaran thirumalai
  28. Praveenkumar Hulakund
  29. Ravinder Thakur
  30. Satya Bodapati
  31. sayantan.dutta
  32. Shivji Kumar Jha
  33. Sujatha Sivakumar
  34. Sunanda Menon
  35. Sunny Bains
  36. Thayumanavar
  37. Tor Didriksen
  38. Venkata Sidagam
  39. Venkatesh Duggirala
  40. Yasufumi Kinoshita

Observations:

  1. All the non-Oracle contributors work for SkySQL (and worked for Monty Program before that)
  2. Even when you go back to MariaDB 5.5.23 I can only find evidence for a maximum of 2-3 external contributions of code to MariaDB since then.
  3. In the same time frame (5.5.23-5.5.32) I see 1 or 2 going into Oracle trees, so it’s roughly the same.
  4. If you look at the contributors from Oracle over 5.5.23 to 5.5.32 there are closer to twice as many as the 40 listed above.

Somebody please correct me if I’m wrong here… perhaps MariaDB guys are just really bad at clearly marking commits that come from elsewhere? I’ve looked for “patch.*by”, “original” and “ontributed” and only turned up the above.

Are MariaDB tests adding anything extra over Oracle MySQL tests?

I grabbed all the tests introduced in MariaDB 5.5.32 (i.e. “bzr diff -rtag:mariadb-5.5.31..mariadb-5.5.32 mysql-test/” and some foo) and threw them in their own test file. I only kept tests for crashing bugs and ignored those that required plugins (there were two or three, but nothing major). So now I have a test file that should crash MariaDB 5.5.31 and probably before. But, the question is: does this crash Percona Server or MySQL?

While it is excellent to see the MariaDB guys including tests for their crashing bugs, are these MariaDB specific or do they affect other MySQL flavours?

I built a release build of top of trunk Percona Server and ran the test against it. I got no crashes. In a debug build, I got two. One was to do with REPAIR on an ARCHIVE table and the other was “SELECT UNIX_TIMESTAMP(STR_TO_DATE(‘2020′,’%Y’));”. I found the same thing for a debug build of top of tree MySQL.

All the other tests for crashing bugs, of which there were 14 – were MariaDB specific. So, out of 16 total, only 2 applied to Percona Server and MySQL.

Why do some foods taste absolutely AWESOME on playa? (a theory)

(I originally posted this to our camp mailing list, but I figured that the wider population of the internet may also be interested)

A couple of things prompted me thinking about this, and I shared my thoughts with Leah tonight and she’s been thinking the same kind of things.

We’ve observed that some food on playa is absolutely THE BEST THING EVER to enter our mouth holes while some things are a bit more meh than they should be. Basically,  we’re theorising that human taste buds change at Burning Man when compared to the default world.

A while ago we saw Heston Blumenthal trying to fix airline food, where he conducted an experiment where at sea level and then in a compartment that was pressurized to the altitude of a plane he had different concentrations of sweet, sour, bitter, salty and umami to taste.

So, let’s look at the differences in altitude and humidity between home,
playa and an airplane:

Altitude

Home: within a few hundred ft of sealevel.
Black Rock Desert: 3,907ft (from wikipedia)
Airplane cabin: 6,000ft (Boeing 787) to 6,900ft (Boeing 767) (or much closer to sea level if you’ve got a private jet)

Humidity

Home: 40-80% (inside/outside my house right now)
Airplane: 12-15%
Burning Man: 24% (average for August), low teens during the day (10-15% midday to midnight)

The result of the altitude and humidity for airplanes was:

  • threshold for tasting sweet is increased
    (i.e. need more sweetness to taste it)
  • threshold for tasting sour decreased
    (i.e. more sensitive to sour)
  • threshold for tasting bitter decreased
    (i.e. more sensitive to bitter)
  • threshold for tasting salt is increased
    (i.e. you need more salt)
  • umami was unchanged

This would explain why I always add salt to airplane food, why at one
point corn chips with vegemite was the best thing ever on playa and why
there’s this odd bacon obsession amongst so many.

This also explains why there may be a preference for less hoppy beers on
playa (or, if you’re me, a desire to try some insanely hopped ones to
see if I can notice an intensity increase).

Also, it’s one of the few places I can stomach US sodas (HFCS being
instant diabetes, but ginger ale on playa/in a plane is kinda nice).

One suggestion (and Heston tried this on flights) is nasal
douching… and I’m actually pretty keen to clean out the nose before
eating on playa because as we all know, playa up your nose is a fact of
life.

I’d be pretty interested to conduct some experiments both in normal
conditions and on playa with various concentrations of sweet, sour,
bitter, salty and umami and note down at what concentrations the flavor
is noticed.

I’m thinking:

  • sweet – sugar
  • sour – lemon juice? (store bought so it should be consistent)
  • bitter – not sure here, all i can think of is hops or Bitters
  • salty – salt :)
  • umami – liquid smoke?

Although it may require some experimentation to find what the minimum
concentrations are. Once we’ve worked these out, should be able to do
tasting and take notes when not on playa and then recreate it all on
playa and compare results.

Thoughts?

HOWTO: Build a Monorail

At linux.conf.au 2012 I gave a lightning talk on our Burning man 2010 art installation the Nowhere2Nowhere monorail. I finally extracted the video of just my lightning talk and threw it up on youtube for easy viewing:

popcon-historical: a tool for monitoring package popularity in debian/ubuntu

I’ve just uploaded (where ‘just’ is defined as “a little while ago”) popcon-historical to github. It’s a rather rudimentary way to look at the popcon data from Debian and Ubuntu over time. It loads all the data into a Drizzle database and then has a small perl web-app to generate graphs (and CSV).

Github: https://github.com/stewartsmith/popcon-historical

I’ve also put up a project page on it: https://flamingspork.com/popcon-historical/

An example graph is this one of Percona Toolkit vs Maatkit installs in Ubuntu over time:

You can actually get it to graph any package (which, unlike the graphs on debian.org, the package does not have to be in the Debian archive to graph it over time – it can be a package from third party repos).

“We open source it, and then developers show up and do work for free”

Those who have been around the free and open source software world long enough have heard “We open source it, and then developers show up and do work for free” at least once and have called bullshit on it at least once.

It turns out that people don’t go and work on software for free. They are either modifying software to scratch their own itch (in which case they’re getting 99+% of the code for nothing, so contributing a small bit back is the equivalent of paying for it – with their time rather than money) or it’s a good bit of fun.

So why do software projects that are dual licensed with a commercial license get fewer outside contributions? I think it’s quite simple: people don’t tend to spend their spare time making other people money while making none for themselves. Simply, these projects are left with only contributions from those being paid to work on it (usually by the company who sells the commercial license) and people/companies scratching an itch. Projects that aren’t dual licensed are more likely to have contributors from several companies as then it’s not all-but-one company spending time and money to make another company money.

Stewart’s dot twenty rule

I realised I haven’t written on this for a while and I was asked about it again today.

Stewart’s dot twenty rule is that a piece of software is never really mature until a dot twenty release.

This was a variant of “never use a dot zero release” which has been around the industry for a long time (i.e. always wait for X.0.1).

My first written observation on my variant on this rule was back in 2006:

This is a really stupid metric of software maturity. It is, however, disturbingly accurate.

It seems to continue to be both really stupid and disturbingly accurate. The first few point releases are still going to have rough edges and once you get to about 5 you likely have something that’s intensely usable for a good number of people, by dot 10 the more complex use cases should start to be okay and once you get to dot twenty, then you could say it’s mature.

A topic for another time is how releasing often is one thing but maintaining a release is quite another.

Previously: