[Tails-dev] [Proposal] Redmine workflow simplification: drop…

Supprimer ce message

Répondre à ce message
Auteur: intrigeri
Date:  
À: The Tails public development discussion list
Sujet: [Tails-dev] [Proposal] Redmine workflow simplification: drop "Fix committed" status
Hi,

from my vantage point, the previous iteration on this front (removing
the "QA Check" field¹) seems to have gone pretty well. I've just sent
a call for feedback on that thread.

So here's a proposal for another iteration. My main goal is still to
simplify our workflow; my secondary goal is to gradually make our
workflow closer to GitLab semantics, to lower the amount of change we
have to deal with simultaneously when we'll switch (by May 2020).

Proposal: remove the "Fix committed" status. Instead, use "Resolved".

Theoretical status quo: a ticket is "Fix committed" when it's been
fixed in Git but not released to users yet. Then, a ticket is
"Resolved" once the fix has been release to users.

De facto status quo: during the 4.0 development cycle, most of the
time we did not use "Fix committed". Did this cause trouble?

As far as I can tell, the main purpose of "Fix committed" is to allow
us to list issues that the next Tails release will fix. If we instead
close such issues as "Resolved", we can get the same list, by looking
at the list of "Resolved" tickets with Target version == next release.
I've looked at our doc and it seems to me that all use cases for "Fix
committed" would be satisfied just as well that way.

Did I miss anything? Is there any problem that "Fix committed" solves
for you, on which we would regress if we dropped that status?

If you're fine with this proposal, you may stop reading here.


A number of problems stem from the fact this "Fix committed" status is
mostly specific to Tails. Most other projects I know of have no such
thing (Debian is a notable counter-example with the "pending" tag,
which is needed there because there's no concept of "the next release"
in the Debian bug tracker; ours has no such limitation). So:

- It makes the entry bar for new contributors higher.

- It forces Tails contributors to switch between habits when they
switch back'n'forth upstream contribution (where they have to write
"Closes: #NNN" in commit messages) and Tails work.

- We regularly get this wrong: tickets get closed when they should be
"Fix committed". Under the assumption that we consume this
information, someone — pretty often, yours truly — has to keep an
eye on this and fix mistakes.

For completeness, note that occasionally, we piggy-back on "Fix
committed" to express something else: for example, a blog post whose
copy was finalized but that will be published later. I believe we can
deal with these rare outliers in different ways, and IMO they are not
important enough to justify making things more complex for every
ticket of ours.

[1] https://lists.autistici.org/message/20190324.103611.7aa3cabe.en.html

--
intrigeri