Transition: Issue assigned to Zeeshan Ali

My bugzilla philosophy is like my mail policy: "zero inbox" (even though getting to 0 bugs is impossible but you can try) so I'd really prefer not to have continuous tasks. Any objections on closing this?

I tend to agree and think we might want a different structure.

For example, grouping process improvements and related things, for example by labels.
e.g.

• Measure impact of hits and downloads
• License compliance process for GDP
• etc.

And the things that are technical changes can just be normal tickets to be prioritized in backlog:

• Provide a means of shutting down the platform
• Add support for udisks2 to the GDP image
• etc.

Basically, all of the changes go via Master. We therefore don't need a particular grouping here.

However, some tickets are process-related, or for SDE or CI. So that grouping makes sense.

Some changes are necessary because the team is switching from KanBan to Scrum with regards to tracking. Scrum needs us to treat Epics and Tasks "correctly" (in favor of Tasks and Subtasks)

This Epic serves a small purpose of grouping. The team agreed to have a minimal set of Components for grouping. GDP Master is now a component, and it has the meaning "the embedded system created by GDP Master project" (as opposed to for example Spins, the CIAT system, the SDE). We are not at this time breaking down the project into finer components like HMI, MediaPlayer, and so on.

All the remaining tasks (*in this epic... ongoing for the others) that are not for embedded system (process, CI...) have been designated as such. All other tasks (not only those that are linked to this epic) belong to GDP Master, i.e. they pertain to the embedded system. Whether they belong to releases or not is handled through release planning separate from this.

The grouping we need is done. This EPIC is therefore now done and removed.

Disconnected all still open tasks from the Epic. Closing.