Page MenuHomePureOS Tracker
Create Task
Maniphest T553

unspecified when a PureOS issue is truly "resolved"
Open, NormalPublic
Actions

Description

We track issues for PureOS, and when the issue is resolved we flag it as such.

Typically we flag issues as solved as soon as fix has "landed" - i.e. a) is applied to a package and released to the "landing" suite.
Our users - and colleagues testing - will however continue to experience, and ideally report as broken, until an issue b) has entered "green" suite, or for parts of the default set until c) inclusion in newest installer image.

Which is it? And if answer is "all of them" then how do we uniformly handle that with this issue tracker?

  • Below added by Jeremiah --

Acceptance criteria (AC) for closing this issue: Clear determination of when a PureOS issue should be marked as "resolved"

Related Objects
Search...

Event Timeline

sean.obrien added a subscriber: sean.obrien.Oct 11 2018, 16:14

Suggestion - can we figure out a workflow with subtasks and/or parent tasks? That way there's no need to look outside of this issue tracker for solutions, and we can sort/clean up current tasks here that may be in the kind of limbo you describe.

jeremiah.foster triaged this task as Normal priority.Jan 3 2019, 11:33
jeremiah.foster added a subscriber: jeremiah.foster.Jan 3 2019, 11:45

Having an acceptance criteria (AC) in the issue might help, we can put it in the Description. Having an agreed upon "Definition of Done" is also useful and you've provided an example of DoD we can use, when the issue is in Green.

jeremiah.foster added a comment.Feb 15 2019, 09:00

We should not mark the issue as "resolved" until it is no longer "broken" regardless of whether it is in the installer, green, or landing.

jonas.smedegaard added a comment.EditedApr 10 2021, 10:11

Taking T1027 as an example, I see several options here:
a) we track code project source: issue is done when solved at the code source of what is being packaged
b) we track code project release: issue is done when solved at the code source of what is being packaged and released (e.g. as tarball or git tag)
c) we track packaging project source: issue is done when solved at the packaging source
d) we track packaging project release: issue is done when solved at the packaging source and released (i.e. git tag and pushed to any queue)
e) we track any distribution: issue is done when package is available in any distro release (e.g. landing)
f) we track development distribution: issue is done when package is available in testing distro release (i.e. currently byzantium)
g) we track all distributions: issue is done when package is available in all supported distro releases (i.e. currently amber and byzantium)
h) we require explicitly defined scope: issue can only be done when clarified in issue itself where it is considered done.

I think the sensible thing to do is g).

jonas.smedegaard added a comment.Apr 11 2021, 01:08

The Debian bugtracker has a similar task of tracking issues potentially tied to multiple distro releases, and handles that like g).

jeremiah.foster added a project: Restricted Project.Apr 16 2021, 07:57

Then let's go with g) until / unless we determine this is unsuitable. It may lead to tags like "fixed in Byzantium" or "fixed in Amber" but those ought to be easily managed and I think we already have a "fixed in Byzantium" tag.