forked from OpenXT/openxt
-
Notifications
You must be signed in to change notification settings - Fork 0
JIRA Components
transpute edited this page Sep 18, 2014
·
51 revisions
TO BE DELETED AFTER NEW JIRA SETUP
Some questions:
- Does our JIRA instance support subcomponents so that we can arrange things hierarchically? A flat list will likely need to be vague to prevent the component list from getting too long.
(RP) Hierarchical components would be good, but are unfortunately a ten-year old enhancement request, https://jira.atlassian.com/browse/JRA-846
| Tracker | Orig XT | OpenXT Proposed |
|---|---|---|
| Audio | Audio | Audio |
| Build | Build System | |
| BVT | Automated Test | |
| Dev Infrastructure | ❓ (RP) needed? OpenXT infrastructure is hosted by GitHub or Atlassian. | |
| Device-model (qemu-dm) | Qemu | |
| Documentation | Documentation | Documentation |
| Linux FS | Domain 0 FS | Domain 0 FS |
| Linux Kernel | Domain 0 Kernel | Domain 0 Kernel |
| Graphics Passthrough (PVM) | PCI Passthrough | |
| Hardware Support | Hardware Support and BIOS | OEM Hardware Support & BIOS |
| HCL | HCL Docs | |
| Host Installer | Installer | |
| hvmloader | ❓ (RP) merge with domain builder? | |
| Input Devices | Input (keys, mouse, touchpad) | ❓ HID (Human Interface Device) |
| Linux Kernel | Linux Guest Support | ❓ Guest OS - Linux |
| Linux FS | Linux In-Guest Software | ❓ Guest Tools - Linux |
| Network | NDVM | NDVM ❓ (RP) merge with Device Hardware? |
| Networking | Networking | |
| Non-VM | ❓ (RP) delete? | |
| OEM | ❓ (RP) merge with "HW Support and BIOS"? |
- Audio
- Build System
- (KP) Added, as this is just as important as the code itself and should be tracked appropriately
- Hardware Support
- Input Devices
- Installer
- [KP] Added, as there are known problems to be tagged against this
- Linux FS
- [KP] This is ambiguous. Should this be Dom0 File System?
- Linux Kernel
- [KP] This is ambiguous. Should this be Dom0 Kernel?
-
Management Policy
- [KP] Not sure what this ever really meant.
- Network
- [KP] Should this be renamed to be specific to NDVM? Otherwise is ambiguous
- Passthrough Devices
- [KP] Added to address direct passthrough, such as GFX/NIC/USB controller
- Security Policy
- [KP] Should this be renamed to be Dom0 Security Policy, should it be broken down?
- Stubdom
- Sync-client
- Synchronizer
- TPM/TXT
- USB
- User Interface
- Video
- [KP] Should this be renamed to something like "Switched Graphics"?
- Windows PV Drivers
Do not edit unless something was missed
- Audio
- Documentation
- Hardware Support
- Input Devices
- Linux FS
- Linux Kernel
- Management Policy
- Network
- Security Policy
- Stubdom
- Sync-client
- Synchronizer
- TPM/TXT
- USB
- User Interface
- Video
- Windows PV Drivers
ACPI / WMI AMT - (RP) Drop Audio Build BVT Dev Infrastructure Device model (qemu-dm) Documentation Domain 0 FS Domain 0 Kernel Graphics Passthrough (PVM) Hardware Support and BIOS HCL Host Installer hvmloader Input (keys, mouse, touchpad) Linux Guest Support Linux In-Guest Software NDVM Networking Non-VM OEM Open Source Activities OVF import Power Management Release Note Security SELinux Policy Service VM Status Report Storage Stub domain Supportibility Synchronizer XT Test cases Toolstack Touch TPM / TXT UIVM USB User Interface (Client) V4V VM Graphics - drmplugin and surfman (no PVM) Windows 3rd party drivers Windows 3rd party software (not drivers) Windows Guest Support Windows In-Guest Software Windows PV Drivers Xen Hypervisor XenClient Tools Installer