MariaDB Quality Development Rules
You are viewing an old version of this article. View
the current version here.
The following rules are still being discussed. They are not final yet.
Those are quality-improving rules that everyone with a write access to the MariaDB repository is expected to follow:
- Respect preview releases
- A feature can be pushed into an RC release X.Y.1 only after it was in an earlier preview release. Normally, in X.Y.0, but generally any earlier preview release will do.
- Tester sign-off for all new features
- A feature being in the preview release is a necessary, but not a sufficient condition. It needs to be tested (by a dedicated tester, not a developer) and the tester has to say it's good enough
- Testing might discover bugs, that's normal, they have to be fixed before the feature is pushed (or — at the tester's discretion — they could be fixed after the push, if they're minor)
- Features must not be pushed directly into the GA release bypassing the above
- Keep an eye on the release schedule (https://jira.mariadb.org) to know when the next release is due
- Or simply remember that preview releases happen in Mar/Jun/Sep/Dec, non-preview releases — in the mid-point between preview releases
- Don't push into the red (in buildbot) branch
- Fix failures first (or make sure they're fixed)
- Eventually buildbot will evolve to simply not let you to
- Blocker issues block a release
- we don't release if there's a Blocker bug open, that's why they're called blockers
- so fix them asap, as your first priority, you don't want all the users to wait specifically for you
Comments
Comments loading...
Content reproduced on this site is the property of its respective owners,
and this content is not reviewed in advance by MariaDB. The views, information and opinions
expressed by this content do not necessarily represent those of MariaDB or any other party.
