← Back to team overview

maria-developers team mailing list archive

Re: Documentation for new features


Hi, Colin!

On Jan 03, Colin Charles wrote:
> > On 22 Dec 2015, at 21:56, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> > 
> > Or we can tweak our workflow in Jira somehow to include documentation.
> Don’t close a Jira until after it has passed to documentation. So,
> once a task is complete, it should go to the “documenting” stage.

Is an issue "fixed" if it's in the "Documenting" step?

I mean, from the Jira point of view. When an issue becomes "fixed", it must
have the correct FixVersion (say, 10.1.10, not 10.1), a Component, and a
Resolution (say, "Fixed" or "Not a Bug"). Workflow ensures that all this
is set in all fixed issues.

Logically, as soon as an issue is pushed, it's fixed - at least,
FixVersion, Component, Resolution are known at this point. And if a
release is made when an issue is in the "Documenting" step - the issue
will be in the release, right? So FixVersion *must* be set when an issue
is pushed.

> I do see the “problem” during release phases, but I’m sure we could
> filter out completed Jira’s in the "Documenting" stage (then again, the
> MariaDB Server project shouldn’t release anything that is
> undocumented; so does this then, delay the release?)

There's very little that can delay our release nowadays. And issues in
the "Documenting" step are certainly not it.

I think it's possible to create a workflow where a developer cannot
close an issue, but can only set it to "Documenting" and Ian is the only
one who can move from "Documenting" to "Closed". And Jira treats
"Documenting" issues as fixed.

But then Ian will be a single person who can close issues (not talking
about Incompete, Not a Bug, etc). Is that reasonable? Too much work for
him, and single person will be a bottleneck.

A less extreme option would be to have the above workflow only for
Tasks, but not for Bugs.

Chief Architect MariaDB
and security@xxxxxxxxxxx
Vote for my Percona Live 2016 talks: