[F33] btrfs by default test week 2020-08-31 - 2020-09-07 #634

New issue

Closed

opened 2020-06-26 05:13:12 +00:00 by chrismurphy · 28 comments

chrismurphy commented 2020-06-26 05:13:12 +00:00

Copy link

Change proposal
RHBZ tracker bug
Workstation WG ticket

Advice is solicited from QA (and @'s) to determine goals and scope for a btrfs by default test day. If the change is approved there will be additional test days.

1. The main change sets default_scheme = BTRFS for all desktop variants; ARM variants of desktops will have their kickstarts adjusted to produce btrfs disk images.
2. The change proposal also lists three options (a) /boot on btrfs (b) compression (c) additional subvolumes. These won't be ready for 4 weeks.
3. Also excluded from the change, the install media's rootfs will remain ext4.

Based only on change set (1), for getting an early lead on discovering issues with this change. Just do all the usual test cases for a default installation, for all the desktop variants, but do it with btrfs as the file system.

Example bug that was exposed first on btrfs, but turns out it's due to an assumption that /home and / are on separate file systems.

@ngompa @catanzaro @jkonecny @vponcova @javierm

[Change proposal](https://fedoraproject.org/wiki/Changes/BtrfsByDefault) [RHBZ tracker bug](https://bugzilla.redhat.com/show_bug.cgi?id=1851166) [Workstation WG ticket](https://pagure.io/fedora-workstation/issue/153) Advice is solicited from QA (and @'s) to determine goals and scope for a btrfs by default test day. If the change is approved there will be additional test days. 1. [The main change](https://github.com/rhinstaller/anaconda/pull/2688) sets `default_scheme = BTRFS` for all desktop variants; ARM variants of desktops will have their kickstarts adjusted to produce btrfs disk images. 2. The change proposal also lists three options (a) /boot on btrfs (b) compression (c) additional [subvolumes](https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Are_subvolumes_really_mostly_like_directories.3F). These won't be ready for 4 weeks. 3. Also *excluded* from the change, the [install media's rootfs will remain ext4.](https://pagure.io/releng/issue/9545#comment-660876) Based only on change set (1), for getting an early lead on discovering issues with this change. Just do all the usual test cases for a default installation, for all the desktop variants, but do it with btrfs as the file system. [Example bug](https://gitlab.gnome.org/GNOME/gnome-usage/-/issues/49) that was exposed first on btrfs, but turns out it's due to an assumption that /home and / are on separate file systems. @ngompa @catanzaro @jkonecny @vponcova @javierm

chrismurphy commented 2020-07-03 07:43:46 +00:00

Author

Copy link

Many spins have joined the proposal too, so including those test cases. These are the headlines for what to run; actual test cases I'm looking at are from FC32RC1.3 and offhand I'd say run them all. Maybe emphasis could be made to watch out for certain things? But that sorta is "leading the witness" and I'd rather just see if they run into weird stuff on their own.

Virtualization
- QA:Testcase_Install_to_Previous_KVM - might be enough
Base: Release-blocking environments (x86_64)
Base: Release-blocking environments (ARM)
Base: Modularity
Base: Non-blocking environments (x86_64)
Desktop: Release-blocking desktops: x86 / x86_64
Desktop: Release-blocking desktops: ARM
Desktop: Non release-blocking desktops: x86 / x86_64
Desktop: Non release-blocking desktops: ARM
Sugar (non-blocking, all arches)
Security Lab (should ask)

Many spins have joined the proposal too, so including those test cases. These are the headlines for what to run; actual test cases I'm looking at are [from FC32RC1.3](https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Summary?rd=Test_Results:Current_Summary#Virtualization) and offhand I'd say run them all. Maybe emphasis could be made to watch out for certain things? But that sorta is "leading the witness" and I'd rather just see if they run into weird stuff on their own. Virtualization - QA:Testcase_Install_to_Previous_KVM - might be enough Base: Release-blocking environments (x86_64) Base: Release-blocking environments (ARM) Base: Modularity Base: Non-blocking environments (x86_64) Desktop: Release-blocking desktops: x86 / x86_64 Desktop: Release-blocking desktops: ARM Desktop: Non release-blocking desktops: x86 / x86_64 Desktop: Non release-blocking desktops: ARM Sugar (non-blocking, all arches) Security Lab (should ask)

ngompa commented 2020-07-03 18:59:36 +00:00

Copy link

To make clear what PRs are actually involved here:

• gh#rhinstaller/anaconda#2688
• pagureio#fedora-kickstarts#PR656

To make clear what PRs are actually involved here: * [gh#rhinstaller/anaconda#2688](https://github.com/rhinstaller/anaconda/pull/2688) * [pagureio#fedora-kickstarts#PR656](https://pagure.io/fedora-kickstarts/pull-request/656)

chrismurphy commented 2020-07-04 00:34:32 +00:00

Author

Copy link

If it's a hassle for the first day to create the images we can just have folks do
QA:Testcase partitioning custom btrfs
for starters.

If it's a hassle for the first day to create the images we can just have folks do [ QA:Testcase partitioning custom btrfs ](https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs) for starters.

sumantrom commented 2020-07-04 08:47:23 +00:00

Copy link

@chrismurphy The wiki is ready, I am working on the test day app and I will reach out for the additional test case (if any). On the side, I am running [QA:Testcase partitioning custom btrfs ]
on the latest compose to see how things work.
Are we gonna test for snapshots and other features of brtfs on this test day?
https://fedoraproject.org/wiki/Test_Day:F33_btrfs_by_default_2020-07-08

@chrismurphy The wiki is ready, I am working on the test day app and I will reach out for the additional test case (if any). On the side, I am running [QA:Testcase partitioning custom btrfs ] on the latest compose to see how things work. Are we gonna test for snapshots and other features of brtfs on this test day? https://fedoraproject.org/wiki/Test_Day:F33_btrfs_by_default_2020-07-08

chrismurphy commented 2020-07-04 09:10:47 +00:00

Author

Copy link

Cool thanks.

Yeah, maybe an optional test? User creates subvolume in ~/ and fallocates a large file in it. Then snapshots a few times. Now meander around the desktop and apps that do space reporting, and sanity check.

Cool thanks. Yeah, maybe an optional test? User creates subvolume in ~/ and fallocates a large file in it. Then snapshots a few times. Now meander around the desktop and apps that do space reporting, and sanity check.

sumantrom commented 2020-07-04 09:13:47 +00:00

Copy link

Cool thanks.
Yeah, maybe an optional test? User creates subvolume in ~/ and fallocates a large file in it. Then snapshots a few times. Now meander around the desktop and apps that do space reporting, and sanity check.

Roger that, I will write up something as an optional test case

> Cool thanks. > Yeah, maybe an optional test? User creates subvolume in ~/ and fallocates a large file in it. Then snapshots a few times. Now meander around the desktop and apps that do space reporting, and sanity check. Roger that, I will write up something as an optional test case

chrismurphy commented 2020-07-04 09:15:16 +00:00

Author

Copy link

I wonder if the actual test day should just be 'Btrfs test day', or 'Desktop on Btrfs test day'? I named the QA ticket after the change proposal. But it's not an accepted change so it seems presumptuous. Any ideas? I guess it also depends on whether we use test day specific media or just use custom partitioning.

I wonder if the actual test day should just be 'Btrfs test day', or 'Desktop on Btrfs test day'? I named the QA ticket after the change proposal. But it's not an accepted change so it seems presumptuous. Any ideas? I guess it also depends on whether we use test day specific media or just use custom partitioning.

sumantrom commented 2020-07-04 10:17:03 +00:00

Copy link

@chrismurphy the test day is set around any changeset and we have named it mostly in association with the proposal name. It doesn't really matter if it's accepted on not, if it's a changeset and we want to gather some feedback around, i would still like to keep it btrfs by default. However, I will hold my breath for @adamwill and @kparal views on this

@chrismurphy the test day is set around any changeset and we have named it mostly in association with the proposal name. It doesn't really matter if it's accepted on not, if it's a changeset and we want to gather some feedback around, i would still like to keep it btrfs by default. However, I will hold my breath for @adamwill and @kparal views on this

sumantrom commented 2020-07-04 10:21:05 +00:00

Copy link

Metadata Update from @sumantrom:

• Issue assigned to sumantrom
• Issue tagged with: test days

**Metadata Update from @sumantrom**: - Issue assigned to sumantrom - Issue tagged with: test days

sumantrom commented 2020-07-04 11:38:18 +00:00

Copy link

@chrismurphy The results page is https://testdays.fedorainfracloud.org/events/88

@chrismurphy The results page is https://testdays.fedorainfracloud.org/events/88

chrismurphy commented 2020-07-07 01:07:08 +00:00

Author

Copy link

I wonder if we should explicitly invite folks to do testing on VM's to avoid running into difficulty with Custom partitioning? We do need baremetal testing too so I don't want to detour people from doing that, but custom partitioning is much easier to an empty disk than it is to have to do a partial tear down to make space.

I wonder if we should explicitly invite folks to do testing on VM's to avoid running into difficulty with Custom partitioning? We do need baremetal testing too so I don't want to detour people from doing that, but custom partitioning is much easier to an empty disk than it is to have to do a partial tear down to make space.

chrismurphy commented 2020-07-08 06:40:52 +00:00

Author

Copy link

Eek! I missed this whole section of test cases.

• Guided storage configuration

Eek! I missed this whole section of test cases. - Guided storage configuration

sumantrom commented 2020-07-08 06:56:06 +00:00

Copy link

Eek! I missed this whole section of test cases.

• Guided storage configuration

No issues will be fixed in a couple of mins

> Eek! I missed this whole section of test cases. > - Guided storage configuration No issues will be fixed in a couple of mins

sumantrom commented 2020-07-08 07:03:23 +00:00

Copy link

Eek! I missed this whole section of test cases.

• Guided storage configuration

Updated : https://testdays.fedorainfracloud.org/events/88 with all Guided test cases

> Eek! I missed this whole section of test cases. > - Guided storage configuration Updated : https://testdays.fedorainfracloud.org/events/88 with all Guided test cases

sumantrom commented 2020-08-05 09:41:57 +00:00

Copy link

@chrismurphy, @kparal and @sumantrom are wondering when can we have another test day ?
Also, we have some ideas to suggest users to test:

1. Having two different types of storage types like, most of the users these days have a SSD and an additional HDD.
2. Testing with two different types of partitions
3. Dual boots with current stable and F31
   Other than these, we are asking desktop team to put as many corner cases.. so we can write up test cases which ensure some degrees of better coverage

Also since there are opetions like defrag the disk at certain intervals as feature, @kparal proposed that we should ensure there is a default value that is followed by the upstream and if we are supposed to change those in WS then we must have that covered in some test case as well.

@chrismurphy, @kparal and @sumantrom are wondering when can we have another test day ? Also, we have some ideas to suggest users to test: 1. Having two different types of storage types like, most of the users these days have a SSD and an additional HDD. 2. Testing with two different types of partitions 3. Dual boots with current stable and F31 Other than these, we are asking desktop team to put as many corner cases.. so we can write up test cases which ensure some degrees of better coverage Also since there are opetions like defrag the disk at certain intervals as feature, @kparal proposed that we should ensure there is a default value that is followed by the upstream and if we are supposed to change those in WS then we must have that covered in some test case as well.

chrismurphy commented 2020-08-06 03:48:06 +00:00

Author

Copy link

Kernel 5.8 is just out. About the earliest I expect to see kernel 5.9-rc1 is August 17. There won't be any big new Btrfs features, just fixes and performance improvements. We can test using either kernel, but may end up finding bugs (video, wifi) other than Btrfs if we use only an early rc kernel.

I'm not aware of any plan for scheduled defragmenting by default. There is an idea to set autodefrag with an XATTR on specific directories if the drive is (a) self-reports as rotational, and (b) SCSI-based including SAS or SATA, i.e. not USB.

I'm working on a Fedora Magazine article as my top priority, and tentatively plan to incorporate recruitment for the test week. A completely separate Fedora Magazine article, in the Kernel Test Week style, can be land before or after. But maybe we should schedule some time to talk about the test day parameters at either the next QA meeting or plan to chat about it on #fedora-qa?

Kernel 5.8 is just out. About the earliest I expect to see kernel 5.9-rc1 is August 17. [There won't be any big new Btrfs features, just fixes and performance improvements.](https://lore.kernel.org/linux-btrfs/cover.1596213437.git.dsterba@suse.com/) We can test using either kernel, but may end up finding bugs (video, wifi) other than Btrfs if we use only an early rc kernel. I'm not aware of any plan for scheduled defragmenting by default. There is an idea to set autodefrag with an XATTR on specific directories if the drive is (a) self-reports as rotational, and (b) SCSI-based including SAS or SATA, i.e. not USB. I'm working on a Fedora Magazine article as my top priority, and tentatively plan to incorporate recruitment for the test week. A completely separate Fedora Magazine article, in the Kernel Test Week style, can be land before or after. But maybe we should schedule some time to talk about the test day parameters at either the next QA meeting or plan to chat about it on #fedora-qa?

chrismurphy commented 2020-08-20 16:38:45 +00:00

Author

Copy link

We have agreed upon dates for a btrfs in Fedora test week: 31 Aug - 7 Sep.

Updates:

• Fedora 33 will ship with kernel 5.8. Rebase to 5.9 will happen soon after GA.
• Compression and autodefrag won't be enabled by default anywhere, for F33.
• Fedora Magazine article Btrfs Coming to Fedora 33 will publish Monday but doesn't have any test recruitment component. We might want a separate short article to do that.

Test ideas:

It's a guessing game to try to discover an issue that's both new and likely. If I suggest areas where I think we could find issues, then we might end up biasing the testing to look for obscure things that end up not being relevant to release standards. But I'm happy to help suggest ways of sabotaging things upon request, because I definitely do not think the Change should be treated with kid gloves.

We have agreed upon dates for a btrfs in Fedora test week: 31 Aug - 7 Sep. Updates: - Fedora 33 will ship with kernel 5.8. Rebase to 5.9 will happen soon after GA. - Compression and autodefrag won't be enabled by default anywhere, for F33. - Fedora Magazine article [*Btrfs Coming to Fedora 33*](https://discussion.fedoraproject.org/t/btrfs-by-default/22020/24?u=cmurf) will publish Monday but doesn't have any test recruitment component. We might want a separate short article to do that. Test ideas: It's a guessing game to try to discover an issue that's both new and likely. If I suggest areas where I think we could find issues, then we might end up biasing the testing to look for obscure things that end up not being relevant to release standards. But I'm happy to help suggest ways of sabotaging things upon request, because I definitely do not think the Change should be treated with kid gloves.

sumantrom commented 2020-08-21 13:52:51 +00:00

Copy link

We have agreed upon dates for a btrfs in Fedora test week: 31 Aug - 7 Sep.

Updates:

• Fedora 33 will ship with kernel 5.8. Rebase to 5.9 will happen soon after GA.
• Compression and autodefrag won't be enabled by default anywhere, for F33.
• Fedora Magazine article Btrfs Coming to Fedora 33 will publish Monday but doesn't have any test recruitment component. We might want a separate short article to do that.

Test ideas:

It's a guessing game to try to discover an issue that's both new and likely. If I suggest areas where I think we could find issues, then we might end up biasing the testing to look for obscure things that end up not being relevant to release standards. But I'm happy to help suggest ways of sabotaging things upon request, because I definitely do not think the Change should be treated with kid gloves.

Hey Chris,

Thanks for updating. One more question, we will be using the latest F33 for this test day right?

> We have agreed upon dates for a btrfs in Fedora test week: 31 Aug - 7 Sep. > > Updates: > > - Fedora 33 will ship with kernel 5.8. Rebase to 5.9 will happen soon after GA. > - Compression and autodefrag won't be enabled by default anywhere, for F33. > - Fedora Magazine article [*Btrfs Coming to Fedora 33*](https://discussion.fedoraproject.org/t/btrfs-by-default/22020/24?u=cmurf) will publish Monday but doesn't have any test recruitment component. We might want a separate short article to do that. > > Test ideas: > > It's a guessing game to try to discover an issue that's both new and likely. If I suggest areas where I think we could find issues, then we might end up biasing the testing to look for obscure things that end up not being relevant to release standards. But I'm happy to help suggest ways of sabotaging things upon request, because I definitely do not think the Change should be treated with kid gloves. Hey Chris, Thanks for updating. One more question, we will be using the latest F33 for this test day right?

chrismurphy commented 2020-08-21 16:58:50 +00:00

Author

Copy link

we will be using the latest F33 for this test day right?

Yes. I'd say a clean install from any nightly since branch, with updates installed, is fine. A specific test day image isn't needed.

>we will be using the latest F33 for this test day right? Yes. I'd say a clean install from any nightly since branch, with updates installed, is fine. A specific test day image isn't needed.

sumantrom commented 2020-08-25 13:51:36 +00:00

Copy link

@chrismurphy
https://fedoraproject.org/wiki/Test_Day:2020-08-31_Btrfs_default
https://testdays.fedorainfracloud.org/events/92
https://apps.fedoraproject.org/calendar/meeting/9797/
I am working towards a magazine article and commblog post
will update this

@chrismurphy https://fedoraproject.org/wiki/Test_Day:2020-08-31_Btrfs_default https://testdays.fedorainfracloud.org/events/92 https://apps.fedoraproject.org/calendar/meeting/9797/ I am working towards a magazine article and commblog post will update this

chrismurphy commented 2020-08-27 19:10:41 +00:00

Author

Copy link

My #1 wish list for this test week is really for folks to install and commit to using it normally for a week and report any and all issues, concerns, questions that come up. It's an unusual test case but the one most likely to reveal overlooked problems, in particular integration, I think.

Installer, suspend to RAM, and suspend to disk, are also very relevant tests to focus on.

What about incorporating docs review? I'm thinking just identify stale/misleading things for update, not asking folks to fix it up (unless they want to).

Hopefully, we will have a draft troubleshooting/repair sequence advice by next week.

My #1 wish list for this test week is really for folks to install and commit to using it normally for a week and report any and all issues, concerns, questions that come up. It's an unusual test case but the one most likely to reveal overlooked problems, in particular integration, I think. Installer, suspend to RAM, and suspend to disk, are also very relevant tests to focus on. What about incorporating docs review? I'm thinking just identify stale/misleading things for update, not asking folks to fix it up (unless they want to). Hopefully, we will have a draft troubleshooting/repair sequence advice by next week.

kparal commented 2020-08-31 14:40:24 +00:00

Owner

Copy link

The announcement says:

1. Install use it normally for a week and report any and all issues,
   concerns, questions that come up

2. Testing the BlivetGUI installer options along with the Custom
3. Suspend to RAM
4. Suspend to Disk
5. Reinstalling F33 on an installed Fedora partition and preserving
   /home and its data
6. Help find outdated docs and report them to QA team and WS team

I'm not really seeing any test cases for 2, 3, 4 and 6. Shouldn't they be there?

The announcement says: > 1. Install use it normally for a week and report any and all issues, concerns, questions that come up 2. Testing the BlivetGUI installer options along with the Custom 3. Suspend to RAM 4. Suspend to Disk 5. Reinstalling F33 on an installed Fedora partition and preserving /home and its data 6. Help find outdated docs and report them to QA team and WS team I'm not really seeing any test cases for 2, 3, 4 and 6. Shouldn't they be there?

sumantrom commented 2020-09-01 05:11:47 +00:00

Copy link

The announcement says:

1. Install use it normally for a week and report any and all issues,
   concerns, questions that come up

2. Testing the BlivetGUI installer options along with the Custom
3. Suspend to RAM
4. Suspend to Disk
5. Reinstalling F33 on an installed Fedora partition and preserving
   /home and its data
6. Help find outdated docs and report them to QA team and WS team

I'm not really seeing any test cases for 2, 3, 4 and 6. Shouldn't they be there?

2 is updated on the test matrices
3,4 is being worked on and 6 will be on the expolatory testing

> The announcement says: > > 1. Install use it normally for a week and report any and all issues, > concerns, questions that come up > 2. Testing the BlivetGUI installer options along with the Custom > 3. Suspend to RAM > 4. Suspend to Disk > 5. Reinstalling F33 on an installed Fedora partition and preserving > /home and its data > 6. Help find outdated docs and report them to QA team and WS team > > I'm not really seeing any test cases for 2, 3, 4 and 6. Shouldn't they be there? 2 is updated on the test matrices 3,4 is being worked on and 6 will be on the expolatory testing

chrismurphy commented 2020-09-01 05:40:53 +00:00

Author

Copy link

There's swaponzram test cases that mostly fit for 3 and 4. Once change, use systemctl suspend and systemctl hibernate.

There's swaponzram test cases that mostly fit for 3 and 4. Once change, use `systemctl suspend` and `systemctl hibernate`.

chrismurphy commented 2020-09-01 20:32:16 +00:00

Author

Copy link

Maybe add this
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_rescue_mode

Fedora-Everything-netinst-x86_64-33-20200829.n.0.iso does rescue a custom btrfs layout.

Maybe add this https://fedoraproject.org/wiki/QA:Testcase_Anaconda_rescue_mode Fedora-Everything-netinst-x86_64-33-20200829.n.0.iso does rescue a custom btrfs layout.

kparal commented 2020-09-02 08:01:31 +00:00

Owner

Copy link

Maybe add this
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_rescue_mode

Added

> Maybe add this > https://fedoraproject.org/wiki/QA:Testcase_Anaconda_rescue_mode Added

sumantrom commented 2020-10-08 09:36:20 +00:00

Copy link

The BTRFS test week happened and we had 1020 test runs and 105 testers participating.
Test results have been moved to https://fedoraproject.org/wiki/Test_Day:2020-08-31_Btrfs_default#Test_Results

The BTRFS test week happened and we had 1020 test runs and 105 testers participating. Test results have been moved to https://fedoraproject.org/wiki/Test_Day:2020-08-31_Btrfs_default#Test_Results

sumantrom commented 2020-10-08 09:36:28 +00:00

Copy link

Metadata Update from @sumantrom:

• Issue close_status updated to: Fixed
• Issue status updated to: Closed (was: Open)

**Metadata Update from @sumantrom**: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)

sumantrom was assigned by kparal 2026-01-22 11:36:50 +00:00

adamwill added the

Priority

Medium

label 2026-02-10 20:23:29 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

No results found.

Labels

Clear labels   

agile

related to Scrum or other Agile methodology

  

anacondawebui

tickets relating to the anaconda 'web ui' interface refresh

  

arm

  

blockerfe

Issues relating to the blocker / freeze exception process

  

Closed As

Duplicate

Closed with the reason of Duplicate

  

Closed As

Fixed

Closed with the reason of Fixed

  

Closed As

Invalid

Closed with the reason of Invalid

  

Closed As

Wontfix

Closed with the reason of Wontfix

  

Closed As

Worksforme

Closed with the reason of Worksforme

  

coreos

issue related to coreos

  

criteria

release criteria-related issues

  

defect

  

easyfix

  

enhancement

  

iot

Issues related to IoT

  

meeting

a topic for the next QA meeting

  

meta

issues in the issue tracker itself (like, whooooaaa, man)

  

onboarding call

issues that are used to track new contributor onboarding

  

proventesters

  

retrospective

issues filed as a result of QA Retrospective feedback

  

silverblue

Issues related to silverblue

  

sponsor

requests to become a FAS group sponsor

  

test cases

  

test days

  

wiki

  

Backlog Status

Needs Review

Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  

Backlog Status

Ready

Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and can be worked on immediately when capacity is available.

  

chore

Work that needs to be done but doesn't add new functionality or fix bugs. Maintenance tasks that keep the system running smoothly and the codebase clean.

  

documentation

Work focused on creating, updating, or improving documentation for users, developers, or system administrators.

  

points

01

A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  

points

02

This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  

points

03

Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  

points

05

A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  

points

08

Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  

points

13

Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  

Priority

Critical

This is for work that is urgent and of critical importance and so and must be addressed immediately with a higher priority than all other work, even if not originally planned for the current sprint.

  

Priority

High

This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  

Priority

Low

This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  

Priority

Medium

This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  

Sprint Status

Blocked

Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  

Sprint Status

Done

Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  

Sprint Status

In Progress

Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  

Sprint Status

Review

Work items that are complete but need review, testing, or approval before being marked as done.

  

Sprint Status

To Do

Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  

Technical Debt

Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  

Work Item

Bug

Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  

Work Item

Epic

Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  

Work Item

Spike

Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  

Work Item

Task

Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  

Work Item

User Story

User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels

agile

anacondawebui

arm

blockerfe

Closed As

Duplicate

Closed As

Fixed

Closed As

Invalid

Closed As

Wontfix

Closed As

Worksforme

coreos

criteria

defect

easyfix

enhancement

iot

meeting

meta

onboarding call

proventesters

retrospective

silverblue

sponsor

test cases

test days

wiki

Backlog Status

Needs Review

Backlog Status

Ready

chore

documentation

points

01

points

02

points

03

points

05

points

08

points

13

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Sprint Status

Blocked

Sprint Status

Done

Sprint Status

In Progress

Sprint Status

Review

Sprint Status

To Do

Technical Debt

Work Item

Bug

Work Item

Epic

Work Item

Spike

Work Item

Task

Work Item

User Story

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

sumantrom

4 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

quality/tickets#634

No description provided.