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 _______________________________________________ Tails-dev mailing list [email protected] https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
