• We are using JIRA to manage the MariaDB project. Go to jira.mariadb.org and click on "Projects" to get to the MariaDB project. Browse around the unresolved and unassigned issues to see if there is something that interests you. Some issues have sponsors and you can be paid for doing them!

• A list of beginner friendly tasks is also available.

• Check the development plans for the next MariaDB version.

• Join maria-developers and ask for suggestions of tasks you could do. Please include your programming experience and your knowledge of the MariaDB source and how much you know about using MySQL/MariaDB with the email so that we know which tasks we can suggest to you.

• If this is your first project, check out the page. It lists projects that will make a good start.

• Join MariaDB's Zulip instance at and ask for suggestions.

• Join #/maria on and ask for suggestions.

If you have your own ideas, please submit them to JIRA so other MariaDB developers can comment on them and suggest how to implement them. You can of course also use the maria-developers list for this.

What to Expect From a MariaDB Server Developer

This section is mainly directed to developers with commit rights to the MariaDB git repository. However, we hope it’s also useful for anyone wanting to contribute code to MariaDB to know what a reviewer will expect from them.

This is not about coding style or if one should prefer C instead of C++. That would be a separate topic that should be created sooner or later.

The Basics

When coding, try to create code that 'never has to be changed again'. Try to make the code as performant as possible. In general it is acceptable to spend 50% more time to make the code 15% faster than what you originally intended. Take that into account when you plan your time estimates! That said, don't try to add classes or functionality that is not yet used.

The code should be easy to read and follow the coding standards of the project. Patches that are smaller and simpler are often better than complex solutions. Don't make the server depend on new external libraries without first checking with Sergei or Monty!

Add code comments for anything that is not obvious. When possible, use assertions within the code to document expectations of arguments etc. In general, if the code requires complex comments, think if there is a better way to structure the logic. Simpler is often better and with fewer bugs.

What to Have in a Commit Comment

• Jira issue number and summary ex:MDEV-23839 innodb_fast_shutdown=0 hang on change buffer merge

• An empty line

• A short description of the problem

• A description of the solution

• Any extra information needed to understand the patch

• The commit message should be self contained and the reviewer shouldn't preferably have to look at the Jira at all to understand the commit. This doesn’t mean that the commit message should include all background and different design options considered, as the Jira should contain.

• Name of all reviewers and authors should be clear from the commit message. The preferred way would be (one line per person)

  • Reviewed-by: email

  • Co-authored-by: email

  • See for details

• The default is that all code should be reviewed. Only in really extraordinary cases, like merge (where the original code was already reviewed) then it can be self-reviewed, which should clear from the commit. In this case the code should of course be tested extra carefully both locally and in buildbot before pushing.

Testing

• All code should have a test case that shows that the new code works or, in case of a bug fix, that the problem is fixed! It should fail with an unpatched server and work with the new version. In the extreme case that a test case is practically impossible to do, there needs to be documentation (in the commit message, optionally also in Jira) how the code was tested.

• The test case should have a reference to the Jira issue, if such one exists.

• Patches related to performance should be tested either by the developer (for simple commits) or by performance testers. The result should be put in Jira with a summary in the commit.

• Complex patches and should be tested by QA in a bb- branch before pushing. The Jira entry should include information that this has been done and what kind of test has been run.

  • Example: git push --force origin HEAD:bb-11.8-MDEV-1234

• For anything not trivial, one should run either Valgrind or ASAN/MSAN on the new code. (Buildbot will do this for you if you can’t get valgrind or ASAN to work). At least the test case added should be tested by either. If the developer cannot do that for some reason, he should check the buildbot builders that do this and ensure that at least his test case doesn’t give any warnings about using not initialized memory or other failures.

• For complex code the developer should preferably use gcov or some similar tool to ensure that at least not all not-error branches are executed. “mtr --gcov” or “dgcov.pl” can help you with this.

Getting Your Code into the Main MariaDB Tree

All code in MariaDB comes from one of the following sources:

• MySQL

• Code developed by people employed by the MariaDB Foundation.

• Code developed by people employed by MariaDB Corporation.

• Code shared with the MariaDB Foundation under the MCA.

• Code with a known origin that is under a permissive license (BSD or public domain).

If you want the code to be part of the main MariaDB tree, you also have to give the MariaDB Foundation a shared copyright to your code. This is needed so that the foundation can offer the code to other projects (like MySQL).

You do this by either:

1. Signing the MariaDB Contributor Agreement (MCA) and then scanning and sending it to the foundation.

2. Sending an email to maria-developers where you say that your patch and all fixes to it are provided to the MariaDB Foundation under the MCA.

3. Licensing your code using the BSD license.

We need shared copyright for the following reasons:

1. to defend the copyright or GPL if someone breaks it (this is the same reason why the Free Software Foundation also requires copyright assignment for its code)

2. to be able to donate code to MySQL (for example to fix security bugs or new features)

3. to allow people who have a non-free license to the MySQL code to also use MariaDB (the MCA/BSD allows us to give those companies the rights to all changes between MySQL and MariaDB so they can use MariaDB instead of MySQL)

More information about the MCA can be found on the MCA FAQ page.

Before Pushing Code to a Stable Branch

• Ensure that you have compiled everything for your new code, in a debug server (configured with cmake -DCMAKE_BUILD_TYPE=Debug ) including embedded and all plugins that may be affected by your code change..

• Run the mysql-test-run (mtr) test suite locally with your debug server.

• For anything complex the full test suite should be run.

• For something absolutely trivial, at least the main suite must be run.

• Always push first to a bb- branch to test the code. When the bb- branch is green in you can push to the main branch. Take care of checking that Windows builds compiles (take extra care of checking this as this often fails) and that valgrind and msan builds doesn’t show any problems with your new test cases.

  • You can find your push at the link similar to .

• If you have to do a rebase before pushing, you have to start from the beginning again.

• When porting code from third parties (such as MySQL), make sure to attribute copyright to the right owner, in the header of each modified file.

• For example: Copyright © 2000, 2018, Oracle and/or its affiliates. Copyright © 2009, 2020, MariaDB

• The only exception is that if the changes are trivial and the rebase was trivial and the local mysql-test-run worked, then you can push directly to the main branch. Only do this if you are 99% sure there are no issues! * Please don't make us regret that we have made this one exception! When we have protected git branches, then the above rule will be enforced automatically as the protection will take care of this.

Working on a New Project

• First create a Jira entry that explains the problems and the different solutions that can be used to solve the problem. If there is a new syntax include examples of queries and results.

• After getting an agreement of the to-be-used solution, update the Jira entry with the detailed architecture of the suggested solution.

• When the architecture is reviewed, the assigned developer can start coding.

• When the code is ready, the Jira entry should be updated with the reviewer.

• The reviewer checks the code and either approves it to be pushed or gives comments to the developers that should be fixed. In the later case the developer updates the code and gives it back to the reviewer. This continues until the code is approved.

• If the design changes during the project, the design in Jira needs to be updated.

Working on a Bug Fix

• Ensure that the Jira issue is up to date.

• For complex bugs that require redesign, follow the process in "Working on a new project"

• For simpler bugs, one can skip the listing of different solutions and architecture. However one should still document the reason for the bug and how it's fixed or to-be-fixed, in a JIRA comment.

Making Things Easier for Reviewers

• Ensure that code compiles, all MTR test works before asking for a review

• Try to split a bigger project into smaller, self-contained change sets.

• Automatic things, like renames of classes, variables, functions etc is better to be done in a separate commit.

When Reviewing Code

Remember that the stability and security of any project hangs a lot on the reviewers. If there is something wrong with an accepted patch, it's usually the reviewer who is to be blamed for it, as the reviewer was the one who allowed it to go in!

• Ensure that the code is licensed under New BSD or another approved license for MariaDB (basically any open source license not conflicting with GPL) or that the contributor has signed the MCA.

• GPL is only allowed for code from MySQL (as MariaDB is already depending on MySQL code).

• Ensure that commits are not too large. If the code is very large, give suggestions how to split it into smaller pieces. Merge commits, when rebasing is possible, are not allowed, to keep history linear.

• Check that the commits message describes the commit properly. For code that improves performance, ensure that Jira and the commit message contains information about the improvements.

• Check that there are no unexplained changes in old tests.

• Check the quality of the code (no obvious bugs, right algorithms used)

• Check if any code can be simplified or optimized. Using already existing functions, are loops optimal, are mutexes used correctly etc.

• Check that there is an appropriate test case for the code. See ‘testing’ for what is required!

• Ensuring the code follows the coding standard for MariaDB. This document should be created shortly, but in the meantime ask an old MySQL/MariaDB developer if you are unsure.

• Ensuring that the code follows the architecture agreed for in Jira (if it's in Jira).

• Code should be easy to understand (good code comments, good function and variable names etc).

• Ensure you understand every single line of code that is reviewed. If not, ask the developer to add more comments to get things clear or ask help from another reviewer.

• No performance degradations for all common cases.

• Any code that touches any sensitive area (files, communication, login, encryption or security) needs to have another reviewer that is an expert in this area.

See Also

• Getting Started For Developers (mariadb.org)

• Get the Code, Build It, Test It (mariadb.org)

• Writing Good Test Cases for MariaDB Server (mariadb.org)

• Submitting a Pull Request (mariadb.org)

• (for non-developers)

_{This page is licensed: CC BY-SA / Gnu FDL}

We would like the authentication system to be able to authenticate against a LDAP Directory Server.

See .

Skills: C, working knowledge of LDAP

Mentor: Sergei Golubchik

Kerberos authentication plugin

this project is taken

Kerberos is a security mechanism used in a lot of financial institutions. A MySQL plugin that allows authentication against Kerberos is the goal here.

See .

Skills: C/C++, working knowledge of Kerberos

Mentor: Sergei Golubchik

Active Directory authentication plugin

The Microsoft Windows world is all about Active Directory and upstream MySQL Enterprise already has this feature (though its a paid offering). It would be great to have an open source equivalent.

See .

Skills: C/C++, working knowledge of Active Directory/SAMBA, Windows-based development environment

Mentor: Sergei Golubchik, Vladislav Vaintroub

Keystone authentication plugin

Keystone is the OpenStack Identity Service. The idea would be to ensure that MariaDB can authenticate to Keystone directly.

Skills: Python, C/C++

Mentor: Mark Riddoch

Regex enhancements

this project is taken

MySQL and MariaDB use an old regex library, it works bytewise, and thus only supports one byte character set. It needs to be replaced by a modern multi-byte character set aware regex library.

Additionally a much requested REGEX_REPLACE function should be implemented. (See also mysql-udf-regexp for some UDF code that could be used as a starting point for this)

Detailed task description: MDEV-4425

Skills: C/C++

Mentor: Alexander Barkov

Self-Tuning Optimizer

One of the reasons of bad query plans is inadequate cost estimation of individual operations. A cost of reading a row in one engine might be a lot higher than in some other, but optimizer cannot know it. Also, it uses hard-coded constants, assuming, for example, that evaluating a WHERE clause is 5 times cheaper than reading a row from a table.

Obviously, some kind of calibration procedure is needed to get these cost estimates to be relatively correct. It is not easy, because the estimates depend on the actual hardware where MariaDB is run (a cost of a row read is different on HD and SSD), and also — somewhat — on the application.

A simple and low-maintenance solution would be to use self-tuning cost coefficients. They measure the timing and adjust automatically to the configuration where MariaDB is run.

See MDEV-350.

Skills: C/C++

Mentor: Sergei Golubchik

Roles

this project is taken

Roles, close to SQL:2003 standard. See MDEV-4397.

Skills: C/C++

Mentor: Sergei Golubchik

Potential list

suggested development

_{This page is licensed: CC BY-SA / Gnu FDL}

We would like the authentication system to be able to authenticate against a LDAP Directory Server.

See .

Skills: C, working knowledge of LDAP

Mentor: Sergei Golubchik

Self-Tuning Optimizer

this project is taken

One of the reasons for bad query plans is inadequate cost estimation of individual operations. A cost of reading a row in one engine might be a lot higher than in some other, but the optimizer cannot know it. Also, it uses hard-coded constants, assuming, for example, that evaluating a WHERE clause is 5 times cheaper than reading a row from a table.

Obviously, some kind of calibration procedure is needed to get these cost estimates to be relatively correct. It is not easy, because the estimates depend on the actual hardware where MariaDB is run (a cost of a row read is different on HD and SSD), and also — somewhat — on the application.

A simple and low-maintenance solution would be to use self-tuning cost coefficients. They measure the timing and adjust automatically to the configuration where MariaDB is run.

See MDEV-350.

Skills: C/C++

Mentor: Sergei Golubchik

Port InnoDB memcached interface to MariaDB

MySQL 5.6 has a memcached plugin to InnoDB. MySQL 5.7 has improved performance of this. The task would be to port this to run against MariaDB, and make it work against XtraDB/InnoDB for the 10.1 series of MariaDB.

See MDEV-4674 for more.

Skills: C/C++

Mentor: Colin Charles

GIS enhancements to MariaDB

enhancements for 10.1 that we want to work on include adding support for altitude (the third coordinate), as well as making sure we are fully OpenGIS compliant. MDEV-5813

Skills: C

Mentor: Holyfoot

User defined events

User defined events are supported on several other databases in different form and semantics. Events are used to signal a named event in the database. Applications can use named events instead of polling, which uses more resources.

See MDEV-5532 for more.

Skills: C/C++

Mentor: Jan Lindstrom, Sergei Golubchik

Indexes for BLOBs (in MyISAM and Aria)

MyISAM and Aria support special kinds of indexes that only store the hash of the data in the index tree. When two hashes match in the index, the engine compares actual row data to find whether the rows are identical. This is used in internal temporary tables that the optimizer creates to resolve SELECT DISTINCT queries. Normal unique indexes cannot always be used here, because the select list can be very long or include very long strings.

This task is to provide a direct SQL interface to this feature and to allow users to create these indexes explicitly. This way we can have unique constraints for blobs and very longs strings.

Skills: C++

Mentor: Sergei Golubchik

CREATE OR REPLACE, CREATE IF NOT EXISTS, and DROP IF EXISTS

this project is taken

This task is to add support for OR REPLACE and IF EXISTS / IF NOT EXISTS to all CREATE and DROP variants for all objects (where it makes sense). MDEV-5359

Skills: C++

Mentor: Sergei Golubchik

Statistically optimize mysql-test runs by running less tests

this project is taken

This is a research not a coding task. See MDEV-5776

Skills: SQL, Perl/Python or other language of your choice, mathematical statistics

Mentor: Elena Stepanova, Sergei Golubchik

Improved temporary tables

It is a well-known and very old MySQL/MariaDB limitation that temporary tables can only be used once in any query; for example, one cannot join a temporary table to itself. This task is about removing this limitation. MDEV-5535

Skills: C++

Mentor: Sergei Golubchik

Table UDFs

Implement a new plugin type that adds support for table UDFs — loadable User-Defined Functions that return tables, not scalar values.

Skills: C++

Mentor: Sergei Golubchik

GTID support in mysqlbinlog

The mysqlbinlog tool needs to understand global transaction ids. In particular, it should be possible to start and end the dump at the specified GTID. Both when reading binlog files and when connecting to a running server. See MDEV-4989.

If time permits, other client programs could be extended similarly, like mysqldump --master-data or the --sync-with-master command in mysqltest.

Skills: C++

Mentor:

See Also

• See also «GSoC 2014 tasks» list in Jira.

_{This page is licensed: CC BY-SA / Gnu FDL}

List of beginner friendly bugs

List of Tasks

Stored Procedures Documentation

The capabilities of MariaDB Server are critical to producing large-scale applications. The current documentation lacks sufficient examples, and the examples warrant testing. Getting Started content would make this easier to adopt. MariaDB's implementation is based on ISO SQL/PSM.

Getting Started with Connector/C and Connector/J

and provide the ability to access a MariaDB Server from applications built in C/C++ and Java, respectively. The current documentation for these connectors lacks Getting Started guides.

Spider Documentation

The Storage Engine uses partitioning to provide data sharding through multiple servers. This task involves greatly expanding the existing documentation, including more detail about when to use Spider, basic usage, updating the , detailed examples of the effects of the and , as well as the . You will also ensure changes in the most recent Spider releases are properly documented.

Mroonga Documentation

is a full text search storage engine based on Groonga, which is an open-source CJK-ready fulltext search engine using column base. This project involves greatly expanding the existing MariaDB documentation on the use of this storage engine. A detailed tutorial and user guide, including examples of the various Mroonga , and the effects of changing their settings, as well as the parser and .

Translation

You will choose a major language and ensure that a substantial subsection of the documentation is translated into that language. See translations.

Migration Documentation

You will choose a major relational DBMS, and, focusing on the most recent stable releases, document the process to migrate to MariaDB, including MariaDB equivalents to features in that system, and a detailed list of features that exist in one but not the other, as well as possible workarounds. For an example, see the documentation on (bearing that MariaDB is a MySQL fork, and is substantially more similar to MySQL than to other systems).

Loaded from the MariaDB issue tracker Loading Issues from [Jira](https://jira.mariadb.org/issues/?jql=labels=gsdocs19 and project=mdev order by key)

%fields.summary%

%renderedFields.description%

<>

Suggest a Task

Do you have an idea of your own, not listed above? Do let us know!

_{This page is licensed: CC BY-SA / Gnu FDL}

List of Tasks

MariaDB Server

Implement IVFFlat indexing strategy for MariaDB Vector and evaluate performance

Part-time (175h) or full-time project (350h) - depending on scope MariaDB Vector is coming to MariaDB Server to serve AI Workloads. The current indexing strategy will use HNSW, but IVFFlat is a possible alternative that costs fewer resources to create. Having it as an option is desirable.

MDEV-17398 Spatial (GIS) functions in MariaDB

Part-time (175h) or full-time project (350h) - depending on scope

Our GIS functionality is limitted compared to other DBMSes. Given that MariaDB looks to facilitate migration from MySQL, we should be on par. We have a list of functions that are missing in MariaDB compared to MySQL, as described in . Our goal is to have as many of these functions available within MariaDB. Some of the functionality can be ported from MySQL, while others might require implementation from scratch.

Skills needed: Understanding of C++ development. Ability to navigate a large codebase (with help from mentor).Mentors: Anel Husakovic (primary) / Vicențiu Ciorbaru (secondary)

MDEV-16482 MariaDB Oracle mode misses Synonyms

Full-time project 350h

Synonyms are an important feature, particularly as it helps smooth migration from other databases. While the initial project scope seems straightforward, there are a number of aspects that must be considered:

1. Grammar extension

2. Where will the synonyms definitions be stored?

3. How do synonyms map to the underlying privilege system? Who can create a synonym? Who can access a synonym?

4. Do we enforce the underlying object to exists before creating a synonym? What if the underlying object gets dropped?

5. What kind of error messages do we present to the user in various corner cases?

6. How do synonyms interact with replication (row based vs statement based)

7. How do synonyms interact with views (and views execution)

8. How to present synonyms to users (as part of INFORMATION_SCHEMA for instance?)

9. Performance considerations for multiple connections to the database.

Skills needed: Understanding of C++ development. Able to write and discuss various tradeoffs such that we achieve a feature set that makes sense given the database's priorities.Mentors: Vicențiu Ciorbaru (primary) / Michael Widenius (secondary)

MDEV-30645 CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Full-time project 350h

Support generalized triggers like

the latter being a synonym for CREATE EVENT.

• should STARTUP/SHUTDOWN triggers run exclusively? that is, STARTUP trigger is run before any connection is allowed or in parallel with them? Same for SHUTDOWN.

Skills needed: Understanding of C++ development. Able to write and discuss various tradeoffs such that we achieve a feature set that makes sense given the database's priorities.Mentors: Sergei Golubchik

MDEV-21978 make my_vsnprintf to use gcc-compatible format extensions

Part-time project 175h

my_vsnprintf() is used internally in the server as a portable printf replacement. And it's also exported to plugins as a service.

It supports a subset of printf formats and three extensions:

• %smeans that a string should be quoted like anidentifier`

• %b means that it's a binary string, not zero-terminated; printing won't stop at \0, so one should always specify the field width (like %.100b)

• %M is used in error messages and prints the integer (errno) and the corresponding strerror() for it

• %T takes string and print it like %s but if the string should be truncated puts "..." at the end

gcc knows printf formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable printf format checks.

An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions

• %sI to mean "print as an identifier"

• %sB to mean "print a binary string"

• %uE to mean "print an errno"

• %sT to put a "..." as truncation indicator

old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change.

All error messages and all usages of my_vsnprintf should be changed to use the new syntax. One way to do it is to disable old syntax conditionally, only in debug builds. All gcc printf format checks should be enabled.

Skills needed: Understanding of C development.Mentors: Sergei Golubchik

MCOL-5688 Parallel CSV read leveraging Apache Arrow

Full-time project 350h

cpimport is a binary that ingests data into MCS in an efficient manner reducing ingest timings significantly whilst preserving transaction isolation levels.

cpimport is relatively complex facility that reads data from local file/S3 parses it, converts and put into MCS-specific files. cpimport is unable to read a big-sized single CSV file from disk in parallel. Apache Arrow has a CSV read faciilty that can do parallel CSV read. The goal of the project is to replace an existing homebrew CSV parser implemented in cpimport with the one from Apache Arrow.

Skills needed: modern C++.Mentors: Leonid Fedorov

MCOL-4889 Manual vacuum cleaning for on-disk data empty records

Full-time project 350h

Here extent is a unit of group of columnar values and partition is a group of extents that stores all column values for a specific portion of a table. MCS has a notion of an empty value for columnar segment/token files and dictionaries. Empty values are marked with a bit in the special 1 byte auxiliary column that is created for every table. When DELETE removes records from a table the records are marked with empty bit in the auxiliary column. The deleted records become a wasted disk space. The goal of the project is to reclaim the wasted disk space either re-creating the whole partition or moving partition values.

Skills needed: modern C++Mentors: Roman Nozdrin

Suggest a Task

Do you have an idea of your own, not listed above? Do let us know in the comments below (Click 'Login' on the top of the page first)!

_{This page is licensed: CC BY-SA / Gnu FDL}

List of Tasks

MariaDB Server

• MDEV-21978 make my_vsnprintf to use gcc-compatible format extensions (Part-time project - 175h) MariaDB has its own implementation of most standard C libraries. This is to ensure compatibility across different platforms. Over time this library has evolved and is currently not behaving exactly like POSIX standard library. Thus we want to attain the principle of "least-surprise" with this library. Everything that is supported by standard printf functions should function the same with MariaDB's compatibility library extension.

  • Skills needed: C/C++. Project difficulty: easy Mentor Sergei Golubchik

• MDEV-19160 JSON_DETAILED output unnecessarily verbose. (Part Time project - 175h) As is explained in the MDEV in detail, we want to improve JSON_DETAILED function to better suit our development and debugging purposes. This project will aim to clean up the function's implementation as well as introduce test cases as well as potential "nice-to-have" features to make developer's lives easier.

  • Skills needed: C/C++, understand JSON, OOP. Project difficulty: easy Mentor: Vicențiu Ciorbaru / Sergei Petrunia

• Create utility to parse frm files and print their DDL (Full-time project - potential part-time (175 - 350h, depending on scope)) FRM files are what MariaDB uses to store metadata about tables. These files can be used to generate DDL statements (CREATE TABLE ...). We are lacking a utility to parse these files which could in turn make DBAs lives easier. The task of this project is to have this utility implemented, making use of MariaDB's FRM parsing logic. You may have to carry out some refactoring to extract the parsing code into a reusable library, once for MariaDB Server, once for the FRM parsing tool.

  • Skills needed: C/C++, understanding libraries and APIs. Project difficulty: medium to hard, depending on time allocated Mentor Vicențiu Ciorbaru / Sergei Golubchik / Monty Widenius

• Add linear regression functions (Full-time project - 350h) This project consists of implementing dedicated regression functions within MariaDB. The specification of each function will be decided during the project, based on what other competing databases are offering. We will choose an implementation that best matches user expectations. It is the student's job to perform research into at least one other database and come up with exact semantics for each one of the functions in the MDEV.

  • Skills needed: C/C++, understanding of regression functions and mathematics, APIs, OOP. Project difficulty: medium Mentor Vicențiu Ciorbaru

• Client compatible delimiter for mysqltest (Full-time project - potential part-time (175 - 350h, depending on scope)) We have a DELIMITER command that has a different syntax in client and mysqltest mysqltest needs an additional (previous) delimiter in the end of the DELIMITER expression, which confuses and makes it hard to copy and paste simple scripts with stored procedures from one to another. We would like to have a new command (--delimiter=client|mysqltest) with current behavior as default.

  • Expected outcomes: You will learn the C command line tools development minors. You'll get familiar with a part of MariaDB server infrastructure -- testing framework, which is written in C and Perl.

  • Skills required: good C knowledge; ability to use console terminal, ability to build from console. Project difficulty: easy Mentor Nikita Malyavin

• Improve build speed of the server code base (Full-time project - 350h) We have already learned that precompiling the headers improves the build speed five times, however, the standard CMake solution doesn't fit for our comfort of development: CMake PCH generates one "header of headers" and pre-includes it into the each of compilation units. This makes everything that wasn't included by the unit itself be available across the precompiled set. There are the alternative ways of unit precompiling: clang modules and gcc .gch files. We want to prefer it on the per-comiler header.

  • Expected outcomes: You will make a strong practical impact of a high need and show off your mix of analysis and programming skills.

  • Skills required: good C knowledge, some CMake knowledge; ability to use console terminal, ability to build from console. Project difficulty: medium Mentor Nikita Malyavin

• Improve mysqltest language(Full-time project - 350h) mysqltest has a lot of historical problems: ad hoc parser, weird limitations commands added as needed with no view over the total language structure, etc. The purpose of this work would be improvement of the language.

  • Expected outcomes : Rewrite mysqltest interpreter using either a real parser generator, e.g bison, or cleanly hand-written parser, e. recursive descent, that can be easily extended with new functionality. Added missing control structures, for example "else" for an existing "if". Simple expression evaluations without contacting server, i.e math and string comparisons. Added functionality for minimal string manipulation ,e.g substr function.

  • Skills required: good C/C++ knowledge, interest in parsers/interpreter. Project difficulty: medium Mentor Vladislav Vaintroub

• Create a function to check for JSON intersection (Part-time project - 175h) This project aims at implementing JSON_INTERSECT() function between two JSON objects or two JSON arrays. If the two documents are json arrays then we want to return all the common elements between the two arrays. And in case of objects, we want to return all common key value pairs.

  • Skills required: C/C++, OOP, basic understanding of JSON. Project difficulty: easy Mentor Rucha Deodhar, Oleksandr Byelkin

ColumnStore

• MCOL-4995 Research/implement basic vectorized filtering for ARM platforms (Full-time project - 350h) AS of 6.2.2 Columnstore(MCS) supports vectorization on x86_64 platforms only. The goal of the project is to implement a vectorized low-level filtering for ARM platforms using 128bit ARM NEON extention(SVE is optional). Low-level filtering in the context is the simple predicate WHERE filters, e.g. WHERE c1 = 5 AND c2 in (10, 25). Please see the corresponding Jira issue for details.

  • Skills needed: C/C++, understand low-level platform specifics. Project difficulty: medium Mentor Roman Nozdrin

• MCOL-4994 Build/run Columnstore on MacOS (Part-time project - 175h) As of Columnstore(MCS) 6.2.2 there is no way to compile/use the MCS engine on MacOS. The goal of this project is to be able to boostrap MariaDB + basic(maybe rudimentary) MCS on MacOS. There are number of known issues that prevents MCS compilation on MacOS: a number of offending preprocessor macroses/definitions specific for Linux x86_64 combination; MacOS doesn't provide syslog used by MCS as the only log messages sink. Please see the corresponding Jira issue for details.

  • Skills needed: C/C++, MacOS specifics. Project difficulty: easy Mentor Roman Nozdrin

• Implement DISTRIBUTED JSON functions (Full-time project - 350h) As of 6.2.2 Columnstore there are two query execution modes: relatively slow but compatible Table mode and fast Select Handler mode. Table mode execution supports all JSON_* functions and SH mode doesn't support any. We want to add support for JSON_* functions family in SH query execution mode. Please see the corresponding Jira issue for details.

  • Skills needed: C/C++, JSON format. Project difficulty: easy Mentor Roman Nozdrin

Buildbot (CI/CD)

• MDBF-320 Better Grid view for buildbot.mariadb.org (Python / Javascript / Web Dev ( Full-time project 350h) Our CI/CD infrastructure uses a recent version of Buildbot. The GRID view plugin that comes with Buildbot is not adequate for our needs. In this project, you will discuss with your mentor as well as other MariaDB developers on how to best improve the User Experience of Buildbot's grid view for what MariaDB Developers needs to accomplish.

  • Skills needed: Understanding of web-dev technologies like Angular, React, and Javascript related libraries. Python may also be required. Mentor Vlad Bogolin / Andreia Hendea

Suggest a Task

Do you have an idea of your own, not listed above? Do let us know!

_{This page is licensed: CC BY-SA / Gnu FDL}

Also see the List of beginner friendly issues from the MariaDB Issue Tracker.

List of Tasks

MariaDB Server

MDEV-28395 LOAD DATA plugins

Full-time project 350h

LOAD DATA INFILE can flexibly load data into a table from CSV-like files accessible by the mariadbdb process. LOAD XML INFILE can do it for XML files. LOAD DATA LOCAL INFILE and LOAD XML LOCAL INFILE can do it with files accessible by the client, but not by the server. But there are requests to suport loading more file formats and from other locations, for example, from S3.

This project is to implement support for LOAD plugins and refactor the current LOAD code accordingly. There are two kind of plugins — data parser plugin (CSV-like and XML) and transfer plugin (file and LOCAL). Implementing new plugins is not in the scope of this task, this task is mainly about moving existing code around, creating a possibility for new plugins (like JSON or S3).

Skills needed: C++, bisonMentors: Sergei Golubchik

MDEV-36100 Generate vector embeddings automatically on INSERT

Full-time project 350h

Implement a syntax and a plugin API that the server will use to generate embeddings for documents that the user stores in the database. This should allow to simplify significantly the vector pipeline. mariadbd will not generate embeddings internally, it will invoke a plugin to do that.

Skills needed: C++Mentors: Sergei Golubchik

MDEV-36107 expressions in mysqltest

Part-time project 175h

extend mysqltest language to support

• standard arithmetic +, -, *, /, %

• comparisons ==, !=, <, <=, >, >=

• boolean &&, ||, may be ? :

• if possible: string repetition, perl-style x (to replace SELECT REPEAT() in test files)

This should work in commands if, while

Can be done together with MDEV-36108 as a full-time project.

Skills needed: C++Mentors: Sergei Golubchik

MDEV-36108 variable substitutions in mysqltest

Part-time project 175h

extend mysqltest language to support bash-like substitutions:

• ${var}

• ${parameter:offset:length}

• ${#parameter}

• ${parameter/pattern/string/flags}

• may be ${parameterˆ}, ${parameterˆˆ}, ${parameter,}, ${parameter}

• may be ${parameter@function} with functions like u, U, Q, etc

recursive expansion:

• ${${var}}

Can be done together with MDEV-36107 as a full-time project.

Skills needed: C++Mentors: Sergei Golubchik

MDEV-18827 Create utility to parse frm files and print their DDL

Full-time project - potential part-time (175 - 350h, depending on scope)

FRM files are what MariaDB uses to store metadata about tables. These files can be used to generate DDL statements (CREATE TABLE ...). We are lacking a utility to parse these files which could in turn make DBAs lives easier. The task of this project is to have this utility implemented, making use of MariaDB's FRM parsing logic. You may have to carry out some refactoring to extract the parsing code into a reusable library, once for MariaDB Server, once for the FRM parsing tool.

Skills needed: C/C++, understanding libraries and APIs.Mentors: Vicențiu Ciorbaru / Sergei Golubchik

MDEV-9345 Replication to enable filtering on master

Part-time project 175h

The current methods of filtering replication events are limited to either 1) at binlog-write time, which can break point-in-time recovery because some committed transactions will be missing from the binary log, or 2) on the replica, which forces all events on the primary server to always be sent to the replica, which can be a security concern and is also not efficient. This task aims to eliminate these limitations by adding in another point at which replication filtering occurs: on the binlog dump threads. This would allow users to both maintain a consistent binary log, and minimize network traffic by guarding events which are never intended for replication.

Skills needed: C++Mentors: Brandon Nesterenko

Buildbot build statistics dashboard

Part-time project 175h TODO - A more ample description will be created.

Skills needed:Mentors: Vlad Radu

MCOL-4889 Manual extent vacuuming

Full-time project 350h

Here extent is a unit of group of columnar values and partition is a group of extents that stores all column values for a specific portion of a table. MCS has a notion of an empty value for columnar segment/token files and dictionaries. Empty values are marked with a bit in the special 1 byte auxiliary column that is created for every table. When DELETE removes records from a table the records are marked with empty bit in the auxiliary column. The deleted records become a wasted disk space. The goal of the project is to reclaim the wasted disk space either re-creating the whole partition or moving partition values.

Skills needed: modern C++Mentors: Roman Nozdrin

MCOL-5142 Support for recursive CTE

Full-time project 350h

MariaDB Columnstore lacks recursive CTE handling, so as of now Columnstore hands over the processing back to MariaDB Server if a query contains recursive CTE.

Here is the info about the feature:

Skills needed: modern C++Mentors: Leonid Fedorov

MCOL-5598 Support for EXCEPT and INTERSECT SQL expressions

Full-time project 350h

MariaDB Columnstore lacks UNION EXCEPT INTERSECT handling, so as of now Columnstore hands over the processing back to MariaDB Server if a query contains UNION EXCEPT or UNION INTERCEPT

Here is the info about the feature:

Skills needed: modern C++Mentors: Alexey Antipovsky

MCOL-XXX Bloom-filters for data scanning

Full-time project 350h

MariaDB Columnstore lacks indexes so it reads a lot of extra data from disk. This project introduces Bloom-filters to reduce data read from disk during the most IO heavy operation that is scanning.

Skills needed: modern C++Mentors: Roman Nozdrin

MCOL-5758 Reduce the computations in JOINS by simpler Bloom-filter-based pre-joins

Full-time project 350h

Joins are very heavy algorithms, both in computation and/or in memory use. They need to hold a substantial amount of data in memory and perform hashing and other operations on that data. Joins can overflow memory limits and keeping balance between memory use and performance is tricky. Thus we have to filter information thaat is going into joins as much as possible. Columnstore already does great work in that regard, pushing WHERE filters before joins. This particular task is also concerned with that, adding Bloom filters' operations that approximate JOIN results and perform a secondary read to feed into joins data that is highly likely will be used in a join.

Skills needed: modern C++Mentors: Sergey Zefirov

Suggest a Task

Do you have an idea of your own, not listed above? Do let us know in the comments below (Click 'Login' on the top of the page first)!

_{This page is licensed: CC BY-SA / Gnu FDL}

What kind of error messages do we present to the user in various corner cases?

List of Tasks

Support for GTID in mysqlbinlog

The mysqlbinlog client program needs to be updated to support GTID. Here is a suggested list of things to be done:

• The --start-position and --stop-position options should be able to take GTID positions; or maybe there should be new --start-gtid and --stop-gtid options. Like --start-gtid=0-1-100,1-2-200,2-1-1000.

• A GTID position means the point just after that GTID. So starting from GTID 0-1-100 and stopping at GTID 0-1-200, the first GTID output will probably be 0-1-101 and the last one 0-1-200. Note that if some domain is not specified in the position, it means to start from the begining, respectively stop immediately in that domain.

• Starting and stopping GTID should work both with local files, and with--read-from-remote-server. For the latter, there are a couple of extra things that need doing in the master-slave protocol, seeget_master_version_and_clock() in sql/slave.cc.

• At the end of the dump, put these statements, to reduce the risk of those session variables incorrectly spilling into subsequent statements run in the same session:

Probably some more things will come up during the work, but this looks like a reasonable start.

Granted to PUBLIC

Implement the standard behavior for

Also, this statement is supposed to work:

And these should not

Note that

should not list roles and privileges granted to PUBLIC (unless granted to xxx too), but

should, arguably, list them.

Control over memory allocated for SP/PS

SP/PS (Stored Procedures / Prepared Statements) allocates memory till the PS cache of SP will be destroyed. There is no way to see how many memory allocated and if it grows with each execution (first 2 execution can lead to new memory allocation but not more)Task minimum: Status variables which count the memory used/allocated for SP/PS by thread and/or for the server.Other ideas:

• Automatic stop allocation in debugging version after second execution and call exception on attempt.

• Information schema by threads and SP/PS with information about allocated and used memory

Information can be collected in MEM_ROOTs of SP/PS. Storing info about status of mem_root before execution then checking after new allocated memory can be found. MEM_ROOT can be changed to have debug mode which make it read only which can be switched on after second execution.

Add JSON_NORMALIZE function to normalize JSON values

Background is this question on stackexchange:mariadb-compare-json The task is to provide a function that can be used to compare 2 json documents for equality, then name can be e.g JSON_NORMALIZE JSON_COMPACT already takes care of removing spaces, but this is not sufficient. Keys need to be (recursively) sorted , and if spaces are removed, then documents can be compared as binary strings.

Add linear regression functions

The following linear regression functions exist in a number of other DBMSs, such as Oracle, PostgreSQL:

Some have also been added to Columnstore.

Create utility to parse frm files and print their DDL

It would be useful if MariaDB had a utility that was able to parse frm files and print the DDL associated with the table. For example, it would be useful for users who performed a partial backup with mariadb-backup:partial-backup-and-restore-with-mariadb-backup But they forgot to also backup the table DDL, so they can't restore the tables using the following process: mysqlfrm is a tool that already exists that does similar things:mysqlfrm.py But it doesn't seem very user-friendly. It needs to be able to contact the local MariaDB server, and it also needs to be able to spawn a server instance, and it seems to need to be able to create a bunch of files during this process. e.g.:

JSON_DETAILED output unnecessarily verbose

JSON_DETAILED function ( ) is described as

We now got a use case for it: Optimizer Trace output. Optimizer trace is too large to be copied in full, instead we use expressions like

Our experience is that JSON_DETAILED has some room for improvement when it comes to the quality of automatic JSON formatting. Example:

Things to note:

• empty lines at the start (right before/after the "range_scan_alternatives")

• "analyzing_index_merge_union":[] occupies 3 lines where one would be sufficient.

• the same goes for "ranges"

One can look at the JSON pretty-printer that is used by EXPLAIN FORMAT=JSON and optimizer trace. It produces a better result (but it has room for improvement, too.) Extra: in MySQL, the function is called JSON_PRETTY. We should add ability to use this name as an alias.

Histograms: use JSON as on-disk format

Currently, histograms are stored as array of 1-byte bucket bounds (SINGLE_PREC_HB) or 2-byte bucket bounds (DOUBLE_PREC_HB). The table storing the histograms supports different histogram formats but limits them to 256 bytes (hist_size is tinyint).

This prevents us from supporting other kinds of histograms. The first low-hanging fruit would be to store the histogram bucket bounds precisely (like MySQL and PostgreSQL do, for example). The idea of this MDEV is to switch to JSON as storage format for histograms. If we do that, it will:

• Improve the histogram precision

• Allow the DBAs to examine the histograms

• Enable other histogram types to be collected/used. h2. Milestone-1: Let histogram_type have another possible value, tentative name "JSON" when that is set, let ANALYZE TABLE syntax collect a JSON "histogram"

that is, the following should work:

this should produce {"hello":"world"}. h2. Milestone-2: produce JSON with histogram(). &#xNAN;()- the exact format is not specified, for now, print the bucket endpoints and produce output like this:

Milestone-2, part#2: make mysql.column_stats.histogram a blob. h2. Milestone-3: Parse the JSON back into an array Figure out how to use the JSON parser. Parse the JSON data produced in Milestone-2 back. For now, just print the parsed values to stderr. (Additional input provided on Zulip re parsing valid/invalid JSON histograms) h2. Milestone-4: Make the code support different kinds of Histograms Currently, there's only one type of histogram. smaller issue: histogram lookup functions assume the histogram stores fractions, not values. bigger issue: memory allocation for histograms is de-coupled from reading the histograms. See alloc_statistics_for_table, read_histograms_for_table. The histogram object lives in a data structure that is bzero'ed first and then filled later (IIRC there was a bug (fixed) where the optimizer attempted to use bzero'ed histogram) Can histograms be collected or loaded in parallel by several threads? This was an (unintentional?) possibility but then it was disabled (see TABLE_STATISTICS_CB object and its use) h3. Step #0: Make Histogram a real class Here's the commit:3ac32917ab6c42a5a0f9ed817dd8d3c7e20ce34d h3. Step 1: Separate classes for binary and JSON histograms Need to introduce

and a factory function

for now, let Histogram_json::point_selectivity() and Histogram_json::range_selectivity() return 0.1 and 0.5, respectively. h3. Step 2: Demonstrate saving/loading of histograms Now, the code already can:

• collect a JSON histogram and save it.

• when loading a histogram, figure from histogram_type column that this is JSON histogram being loaded, create Histogram_json and invoke the parse function. Parse function at the moment only prints to stderr. However, we should catch parse errors and make sure they are reported to the client. The test may look like this:

h2. Milestone-5: Parse the JSON data into a structure that allows lookups. The structure is

and it holds the data in KeyTupleFormat (See the comments for reasoning. There was a suggestion to use in_vector (This is what IN subqueries use) but it didn't work out) h2. Milestone 5.1 (aka Milestone 44) Make a function to estimate selectivity using the data structure specified in previous milestone. h2. Make range_selectivity() accept key_range parameters. (currently, they accept fractions, which is only suitable for binary histograms) This means Histogram_binary will need to have access to min_value and max_value to compute the fractions.

make my_vsnprintf to use gcc-compatible format extensions

my_vsnprintf() is used internally in the server as a portable printf replacement. And it's also exported to plugins as a service. It supports a subset of printf formats and three extensions:

• %s` means that a string should be quoted like an identifier

• %b means that it's a binary string, not zero-terminated; printing won't stop at \0, so one should always specify the field width (like %.100b)

• %M is used in error messages and prints the integer (errno) and the corresponding strerror() for it

gcc knows printf formats and check whether actual arguments match the format string and issue a warning if they don't. Unfortunately there seems to be no easy way to teach gcc our extensions, so for now we have to disable printf format checks. An better approach would be to use gcc compatible format extensions, like Linux kernel does. We should migrate to a different syntax for our extensions

• %sI to mean "print as an identifier"

• %sB to mean "print a binary string"

• %uE to mean "print an errno"

• %sT to put a "..." as truncation indicator

old formats can still be supported or they can be removed and in the latter case the major version of the service should be increased to signal an incompatible change. All error messages and all usages of my_vsnprintf should be changed to use the new syntax and gcc printf format checks should be enabled.

Add JSON_EQUALS function to check JSON equality

JSON_CONTAINS can be used to test for JSON object equality in some cases, but we seem to lack a clear JSON_EQUALS function.

Concurrent multi-reader, multi-writer buffer for IO_CACHE

IO_CACHE has basically three read/write modes: only read, only write, and a sequential read/write FIFO mode SEQ_READ_APPEND. While some performance-sensitive places, like replication slave thread, use SEQ_READ_APPEND, that may be a bottleneck. since reads and writes are sequential (and co-sequential i.e. reads and writes block each other). The task is to implement a non-blocking mode or multi-reader, multi-writer use-case through a concurrent ring buffer implementation. h2. Possible approaches h3. Lock-free n-consumer, m-producer ring buffer This implementation requires limiting a number of simultaneous accessors and reserving slots for them. Lock-free implementations can contain busy waits, but no locks, except when a number of consumers or producers is exceeded. This can be controlled by a semaphore with a capacity of a number of cores. This is an ideal way, but can be an overhaul because of complicated busy loops and slot management. This is also hard because writes can be bigger than a buffer. See buffer excess. h3. Simple rwlock-based non-blocking approach The bottleneck basically occurs because SEQ_READ_APPEND blocks the whole time during buffer copy. We can avoid it by moving the pointers first, thus allocating a place for copying, and then make a copy from/to the buffer without a lock. rwlock will be used to access the pointers, i.e. reads access IO_CACHE::end_of_file with read lock to make ensure the borders, but writers access it with write lock. h2. Buffer excess Excesses make things work sequential. When the buffer is full, a separate write buffer is created. When the write buffer is full, a flush happens. Flushes wait for all writers to finish first, then lock the write buffer for flushing. The read buffer can be flushed in a more relaxed way: no need to need to lock for flushing, but we have to lock for buffer allocation and wait for all writers. Waiting for writers can be done with another rwlock. h2. Single-readerness The real-world cases are mostly single-consumer, and it is essential for IO_CACHE: it is variable-lengthed, and has no underlying data format, so the reader always has to make at least two sequential reads (one to read size and another to read the body) Single-readerness considerations can relax some conditions and ease the implementation h2. io_cache_reserve api We can add a function to reserve the space to writing for the case of writing big objects (both bigger then the write cache and smaller then the latter, but big enough to not fit to the external buffer), for the cases like copying one cache to another. The function should return future-like object, since we have to notify IO_CACHE back that the writing is finished (to make flush for example)

Custom formatting of strings in MariaDB queries

Formatting more complex strings in a SELECT statement can get awkward when there are many concat(), format(), etc calls involved. It would be very cool and helpful to have a function that takes an input string and a formatting specification and returns string formatted using the rules the user passed in the specification. A great example for such a function is the classic C printf function, which, in this context, would look something like:SELECT printf('%s %s, %s', first_name, last_name, job_title) from employees; But it doesn't necessarily need to look this way, an alternative syntax could be Python-ish, which would leverage the fact that the server already knows the datatype of each field used in the formatting scheme:SELECT sformat('arg1: {}, arg2: {}', col1, col2) from table; In that syntax one passes formatting options within the curly braces:

Ideally, this new function should use, behind the scenes, the existing builtin formatting functions in MariaDB (e.g. date_format(), format()) and even future formatting functions (e.g. MySQL's format_bytes(), format_pico_time()), so the syntax has to be designed in a smart way to accommodate easily future additions.

Add autocompletion capabilities to the MariaDB Jupyter kernel

As part of the Jupyter Messaging protocol, the Jupyter frontend sends a complete_request message to the MariaDB kernel when the user invokes the code completer in a Jupyter notebook. This message is handled in the do_complete function from the MariaDBKernel class. In simpler words, whenever the user hits the key shortcut for code autocompletion in a notebook, the MariaDB kernel's do_complete function is called with a number of arguments that help the kernel understand what the user wants to autocomplete. So the autocompletion infrastructure in the MariaDB kernel is already kindly provided by Jupyter, we only need to send back to Jupyter a list of suggestions based on the arguments that do_complete receives :-). Ideally we should aim to enable at least database, table and column name completion and also SQL keyword completion. But no worries, there are plenty of possibilities to extend the functionality even more if the accepted student turns out to be very productive :D

Implement interacting editing of result sets in the MariaDB Jupyter kernel

At this moment the MariaDB kernel is only capable of getting the results sets from the MariaDB client in HTML format and packing them in a Jupyter compatible format. Jupyter then displays them in notebooks like it would display Python Pandas dataframes. Sure, the users can easily write SQL code to modify the content of a table like they would write in a classical command line database client. But we want to go a bit further, we would love to have the capability to edit a result set returned by a SELECT statement (i.e. double click on table cells and edit) and have a button that users can press to generate a SQL statement that will update the content of the table via the MariaDB server. Apart from interacting with the Jupyter frontend for providing this UI capability, we also have to implement a field integrity functionality so that we make sure users can't enter data that is not compatible with the datatype of the column as it is seen by the MariaDB server. The project should start with a fair bit of research to understand how we can play with the Jupyter Messaging protocol to create the UI functionality and also to check other Jupyter kernels and understand what's the right and best approach for tackling this.

Make the MariaDB Jupyter kernel capable of dealing with huge SELECTs

Currently the MariaDB kernel doesn't impose any internal limits for the number of rows a user can SELECT in a notebook cell. Internally the kernel gets the result set from MariaDB and stores it in a pandas DataFrame, so users can use it with magic commands to chart data. But this DataFrame is stored in memory, so if you SELECT a huge number of rows, say 500k or 1M, it's probably not a very good idea to create such a huge DataFrame. We tested with 500k rows, and the DataFrame itself is not the biggest problem, it consumed around 500MB of memory. The problem is the amount of rows the browser needs to render, for 500k rows the browser tab with the notebook consumes around 2GB of memory, so the Jupyter frontend (JupyterLab, Jupyter Notebook) slows down considerably. A potential solution is to introduce a two new config options which would specify:

• a limit for the number of rows the Jupyter notebook should render, a reasonable default value for this could 50 rows for instance (display_max_rows)

• a limit for each SELECT statement, limit_max_rows, that the kernel would use to determine whether it should store the result set in memory in a DataFrame or store the result set on disk. A reasonable default value might be 100k rows.

The trickiest part of the project though is that, once the kernel writes a result set on disk, the charting magic commands need to detect that the data is not in memory, it is on disk, and they should find a smart mechanism for generating the chart from the disk data without loading the entire data in memory (which would defeat the whole purpose of the project). This might involve finding a new Python plotting library (instead of current matplotlib) that can accomplish the job.

Suggest a Task

Do you have an idea of your own, not listed above? Do let us know!

_{This page is licensed: CC BY-SA / Gnu FDL}