MDEV-39456: Describe the external contributions process in more details by gkodinov · Pull Request #5007 · MariaDB/server

gkodinov · 2026-04-28T13:24:00Z

Added a new COMMUNITY_CONTRIBUTIONS.md document describing the community contribution process.
Added a reference to it from the CONTRIBUTING.md.

bnestere

The process to address a reviewers comments might be good to include, though I don't know if we have a standard for that. I like each round of review having a single incremental commit, so it is easy to follow up and see if just the changes from that round of review are sufficient. Rather than either continually squashing everything into a single commit & having to re-review the whole patch and remember how it used to look; or a lot of very small commits together.

gkodinov · 2026-04-28T15:37:52Z

The process to address a reviewers comments might be good to include, though I don't know if we have a standard for that. I like each round of review having a single incremental commit, so it is easy to follow up and see if just the changes from that round of review are sufficient. Rather than either continually squashing everything into a single commit & having to re-review the whole patch and remember how it used to look; or a lot of very small commits together.

Thanks, I'll think about that. I guess we need to focus on the smaller contributions (90% of them). For these a single commit is just fine. Besides: github will display the changes for each subsequent commit even if it's a single commit. So I'd rather stick to the single commit situation. But it's be interesting to see what do others think.

bnestere · 2026-04-28T15:42:56Z

@gkodinov

Besides: github will display the changes for each subsequent commit even if it's a single commit. So I'd rather stick to the single commit situation.

How? I know of the "compare" button which will git diff the previous and new commit, but if one squashes & rebases to the latest origin/branch in the same push, it becomes meaningless.

grooverdan

Looking really good @gkodinov !

grooverdan · 2026-04-28T21:32:24Z

+  * Assignee: Not relevant
+  * Label: not relevant
+* Jira
+  * State: "Stalled" or "Open"


or "Confirmed"

grooverdan · 2026-04-28T21:38:37Z

+  * contain a concise description of what the change is: this goes to the git commit log and is used for reference.
+  * should contain all the relevant attribution headers (co-authors, reviewers etc.)
+* The pull request should contain at least a copy of the commit message. Ideally more can be added to it. 
+* The pull request should target the right branch. Rule of thumb: the lowest affected activelly supported version for bugs, main branch for features and refactorings.


actively

Link to https://mariadb.org/about/#maintenance-policy.

The fixVersion on a JIRA issue can be used as a guide, but limit to actively supported versions,but not rolling releases about to go EOL.

grooverdan · 2026-04-28T21:43:43Z

+  * should contain all the relevant attribution headers (co-authors, reviewers etc.)
+* The pull request should contain at least a copy of the commit message. Ideally more can be added to it. 
+* The pull request should target the right branch. Rule of thumb: the lowest affected activelly supported version for bugs, main branch for features and refactorings.
+* All the relevant buildbot tests should be passing (or, if failing, the failures should be studied and justified as unrelated)


Maybe more detail:

Compare to the tests that succeed on the target branch ref: https://buildbot.mariadb.org/#/grid?branch=BRANCHNAME

Check test output if assessing that a test failure is identical.

grooverdan · 2026-04-28T21:55:29Z

+* All the relevant buildbot tests should be passing (or, if failing, the failures should be studied and justified as unrelated)
+* The licensing of the pull request should be clear. Ideally the CLA buildbot should be green. If you can't do that mentioning a license in the pull request's description can be a workaround.
+
+Questions and Answers


Move this to the end under its own heading?

Who creates a Jira issue?es

anyone can create a JIRA issue

Can I get a design review of a Jira issue in advance of writing a PR?

Yes, create a zulip topic and ask if no response within a few days.

Does fixing a typo, documentation or code comments really require a Jira issue?

If the issue/change isn't going to make it to a release notes, then a Jira isn't needed.

I've added the first question. I think the 2nd drifts away a bit. There's a way to contact us in CONTRIBUTING.md already.

And I don't agree with the 3d question's answer. It was made very clear to me by the management that everything should get a jira.

grooverdan · 2026-04-28T21:57:32Z

@@ -0,0 +1,196 @@
+# Community Contributions Process #
+


I think a statement of how MariaDB values community contributions would be a good way to begin this document.

A good idea! Adding.

svoj · 2026-04-29T07:40:28Z

The process to address a reviewers comments might be good to include, though I don't know if we have a standard for that. I like each round of review having a single incremental commit, so it is easy to follow up and see if just the changes from that round of review are sufficient. Rather than either continually squashing everything into a single commit & having to re-review the whole patch and remember how it used to look; or a lot of very small commits together.

Every PR update has "compare" button, which gives exactly what you describe. It is also relatively easy to get this effect locally. It can be spoiled by rebase though. OTOH incremental commits in early review stages are probably alright. When it comes closer to merge they need to be squashed anyway.

svoj · 2026-04-29T07:56:13Z

+
+The pull request is used to describe how the bug is fixed. Or how the feature is implemented in detail. 
+
+A pull request should contain a **signle commit**! And that commit should have a commit message that's compliant with the MariaDB coding standards.


We don't follow this rule ourselves. It's be odd if I were forced to use single commit e.g. in #4048.

Commit has to be self-contained isolated change, while PR spans such changes to form a solution.

I can imagine the intention was avoiding incremental commits, probably also unjustified commit splitting. In this case it should be stated clearly and distinguished from justified multi-commit PRs.

well, that's the intent at least. There's always exceptions.

gkodinov · 2026-04-29T11:03:19Z

@gkodinov

Besides: github will display the changes for each subsequent commit even if it's a single commit. So I'd rather stick to the single commit situation.

How? I know of the "compare" button which will git diff the previous and new commit, but if one squashes & rebases to the latest origin/branch in the same push, it becomes meaningless.

I believe they're quite readable.

E.g. take #5011.

The submitter has pushed an initial commit. Then they've updated it with --force. And the Compare link is pretty readable IMHO.

mariadb-AlexHanshaw · 2026-04-29T12:42:26Z

+
+### What should go into the jira ###
+
+The [Jira](https://jira.mariadb.org) is used to describe the design of the


Contributors can save themselves time reworking code if they include implementation details for the bug or feature before they start coding. This provides an opportunity for early feedback that might impact the code solution.

Added:

Tip
A lot of time an energy can be saved, especially on more complex tasks,
by communicating early with possible reviewers and writing down a design
specification into the Jira prior to implementation

mariadb-AlexHanshaw · 2026-04-29T12:50:00Z

+* Jira
+  * State: "Open", "In Progress", "Stalled" or "Needs feedback"
+  * Assignee: The preliminary reviewer
+  * Label: "Contribution"


Why do we have "Contribution" and "External Contribution" labels depending on the review stage? Isn't an external contribution an external contribution through all stages?

It's the pull requests having the "External contributions" label. And Jiras having "contribution". These were pre-existing. Just quoting them here.

bnestere · 2026-04-29T18:53:53Z

@gkodinov

Besides: github will display the changes for each subsequent commit even if it's a single commit. So I'd rather stick to the single commit situation.

How? I know of the "compare" button which will git diff the previous and new commit, but if one squashes & rebases to the latest origin/branch in the same push, it becomes meaningless.
I believe they're quite readable.

E.g. take #5011.

The submitter has pushed an initial commit. Then they've updated it with --force. And the Compare link is pretty readable IMHO.

If a contributor only --force pushes on the same base branch, sure it is ok. But if one also rebases along with the force push it becomes unreadable. E.g, this compare from PR #4766.

Added a new .md document describing the community contribution process. Added a reference to it from the CONTRIBUTING.md.

gkodinov · 2026-04-30T10:41:00Z

@gkodinov

Besides: github will display the changes for each subsequent commit even if it's a single commit. So I'd rather stick to the single commit situation.

How? I know of the "compare" button which will git diff the previous and new commit, but if one squashes & rebases to the latest origin/branch in the same push, it becomes meaningless.
I believe they're quite readable.

E.g. take #5011.
The submitter has pushed an initial commit. Then they've updated it with --force. And the Compare link is pretty readable IMHO.

If a contributor only --force pushes on the same base branch, sure it is ok. But if one also rebases along with the force push it becomes unreadable. E.g, this compare from PR #4766.

You can't win them all. We do not have to account for all the github bugs.

vuvova

See comments inline.

Generic question, should this even be here, in the repository? May be a KB is a more appropriate place for texts like this? Somewhat related texts are in KB

vuvova · 2026-05-03T19:42:06Z

+## The two sides of a contribution
+
+A contribution should have **BOTH** a design document
+ in[Jira](https://jira.mariadb.org) and a pull request


missing space

vuvova · 2026-05-03T19:45:34Z

+The pull request is used to describe the implementation.
+E.g. how the bug is fixed. Or how the feature is implemented in detail.
+
+The pull request should contain a **single commit**!


No, absolutely not. It often can (and should) do with a single commit. But it's not an absolute rule, it depends on the case. If a contributor puts unrelated changes in one commit we will ask him to split it.

Say, one commit = one logical change, add a link to a guideline, if needed (tons of them on the internet). But do not require wrong behavior here, it'll just be more work for contributors and reviewers.

vuvova · 2026-05-03T20:18:18Z

+  * Label: optionally "need feedback" and/or "External Contribution"
+* Jira
+  * State: absent or in "Stalled"/"Open"/"Confirmed"
+  * Assignee: Not relevant. Keep it empty.


do they even can set an assignee?

vuvova · 2026-05-03T20:20:58Z

+  * Assignee: Not relevant, keep empty
+
+Contributions in this state should be ready for review. This means:
+* There should be a single commit in the pull request and this commit must


no, not a single commit

vuvova · 2026-05-03T20:27:55Z

+* The pull request should contain at least a copy of
+  the commit message. Ideally more can be added to it.
+* The pull request should target the
+  [right branch]( https://mariadb.org/about/#maintenance-policy).


not a good link. [right branch] link should point to a document that explains how to select a right branch. We don't have it, so "right branch" should not be a link. Try

The pull request should target the right branch. Rule of thumb: the lowest affected but not older than three years GA branch for bugs, main branch for features and refactorings.

vuvova · 2026-05-03T20:46:00Z

+  * "In review" means that somebody is assigned to review and they are
+     working on it
+  * "Stalled" means that they're waiting on something
+  * "In testing" means a QA engineer is assigned and they are working on


vuvova · 2026-05-03T20:48:27Z

+  * "In testing" means a QA engineer is assigned and they are working on
+     testing this.
+  * "Needs feedback" means that the reviewer needs feedback to proceed
+  * "In progress" means that the reviewer waited for reply by


does it mean that In progress on you means the issue is back to the contributor? In progress is an active state, we have automation to kick inactive In-Progress back to Stalled.

vuvova · 2026-05-03T20:49:07Z

+
+> [!NOTE]
+> There's a requirement that certain contributions need to undergo
+> a quality assurance review. This is usually done for the new features or


s/quality assurance review/separate testing step/

vuvova · 2026-05-03T20:49:37Z

+> There's a requirement that certain contributions need to undergo
+> a quality assurance review. This is usually done for the new features or
+> for more complex and risky bug fixes. If that's the desired state,
+> a QA engineer will be assigned as a final reviewer.


vuvova · 2026-05-03T20:56:51Z

+> The final reviewer is usually the maintainer. And a very busy person!
+> Contributors should make sure to be quick to reply to their questions to
+> keep the process rolling. And should be patient about their replies.
+> They are doing their best to process it as fast as possible.


This doesn't sound nice to me. I'd replace the whole note with, like

Tip
The final reviewer is usually the core server developer. They often work in cycles, timed to match the release schedule, switching between bug fixing and new feature development. If a bug fix PR comes in the middle of the new feature development cycle or vice versa It might take up to a couple of months for a developer to do a review.

bnestere reviewed Apr 28, 2026

View reviewed changes

grooverdan reviewed Apr 28, 2026

View reviewed changes

gkodinov added the MariaDB Foundation Pull requests created by MariaDB Foundation label Apr 29, 2026

svoj reviewed Apr 29, 2026

View reviewed changes

gkodinov force-pushed the 10.11-mdev-39456 branch 2 times, most recently from ea460ce to 7b60769 Compare April 29, 2026 10:56

gkodinov marked this pull request as ready for review April 29, 2026 10:58

gkodinov assigned vuvova Apr 29, 2026

gkodinov requested a review from vuvova April 29, 2026 11:00

mariadb-AlexHanshaw reviewed Apr 29, 2026

View reviewed changes

MDEV-39456: Describe the external contributions process in more details

bafe1a5

Added a new .md document describing the community contribution process. Added a reference to it from the CONTRIBUTING.md.

gkodinov force-pushed the 10.11-mdev-39456 branch from 7b60769 to bafe1a5 Compare April 30, 2026 07:33

vuvova requested changes May 3, 2026

View reviewed changes


		The pull request is used to describe how the bug is fixed. Or how the feature is implemented in detail.

		A pull request should contain a signle commit! And that commit should have a commit message that's compliant with the MariaDB coding standards.


		### What should go into the jira ###

		The [Jira](https://jira.mariadb.org) is used to describe the design of the

Uh oh!

Conversation

gkodinov commented Apr 28, 2026

Uh oh!

bnestere left a comment

Choose a reason for hiding this comment

Uh oh!

gkodinov commented Apr 28, 2026

Uh oh!

bnestere commented Apr 28, 2026

Uh oh!

grooverdan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

grooverdan Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

svoj commented Apr 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkodinov commented Apr 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bnestere commented Apr 29, 2026

Uh oh!

gkodinov commented Apr 30, 2026

Uh oh!

vuvova left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

6 participants

grooverdan Apr 28, 2026 •

edited

Loading