-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all,
The list of issue on https://github.com/QubesOS/qubes-issues is growing, and it's getting harder and harder to maintain. Let me first build some context and explain the situation. Specific questions are at the end of the email. Majority of tickets falls into one of two categories: 1. bugs (something is supposed to work, but it doesn't) - label "T: bug" (660 issues) 2. features (something isn't supposed to work, but it would be useful to have it working) - label "T: enhancement" (587 issues) Lets go deeper: 1. Bugs - I can name a few sub-categories: 1.1. Purely about qubes software packages. This obviously belongs to github-issues. 1.2. Incompatibilities with some software within a VM. This in many cases indeed is about some missing feature an application expects. A recent example[1] is Zoom that tries to show a big transparent window. But since Qubes (intentionally) does not support VM-controlled window transparency, the result is quite bad (a window covering the whole screen). 1.3. Incompatibilities with some hardware. 1.4. Bugs in 3rd-party software we happen to ship with Qubes (as part of distributions we use). 1.5. Bugs not diagnosed enough to assign to any category. This includes also bugs that are hard to reproduce (happens rarely, for very few users). 2. Features - here I don't have such elaborate categories, but still can define some, based on their state nor really their nature: 2.1. Feature requests that makes sense (improve usability or security or both), but are unlikely to be implemented by the core developers team in a foreseeable future. 2.2. Features that are in progress and/or are planned for a specific release. This includes both those developed by the core team, or contributed by community member (or both). ## How to organize them ## The main reason for this email is category 2.1. The great majority of those feature requests won't be implemented ever. But also most are quite good material for community contribution and we do have many excellent examples of such, like: - btrfs/reflink storage pool driver - Archlinux template - generic audio support for HVM domains including Windows (already implemented but not released yet) Generally we have those marked with a milestone "TBD" (previously "Far in the future"). But I wonder if we can do better. The current approach means the list of issues will grow indefinitely by design. This could work fine _if we'd have a method to manage them_ - things like predefined filters, more specific issues metadata to filter on. This BTW may mean github is too limited for this use case. But if we won't have easy and convenient way to manage this issues category, I think they shouldn't be keep open in qubes-issues. I mean, either close (those extremely unlikely to be implemented) or move to another tracker (which may be another github repo, or something else). To give you an idea what I'm talking about, lets take a look at the very recent feature request "Add VeraCrypt and alternative encryption support"[2]. This, as even the author notices, would be useful to extremely small part of qubes users (which already is very small subset of population). But also, for a determined contributor, shouldn't also be very hard to implement. Maybe this can be even reduced to a documented manual steps how to configure such thing. Another criteria could be where such feature could live. Some things require changes in core qubes components, but some can be easily implemented as external packages. And since not long ago, we (finally) have a separate packages repository for such contributions. Features (and perhaps also bugs in them?) targeting qubesos-contrib repository could be tracked in a separate place maybe? Separating things into different places have also downsides: it greatly reduce discoverability. This may result in even higher entry barrier for contributors, but also in more duplicates. This is actually the main reason why we have a common qubes-issues repository, instead of tracking everything in appropriate code repository (leaving alone the fact that some issues are about multiple repositories at once). Now back to bugs categories. Hardware support related issues are tricky to track - some are really about generic Linux support (which then falls into category 1.4), but some are triggered by a specific configuration we use in Qubes OS (which also includes Xen). In some cases, it is hard to tell, especially as reproducing an issue requires a specific hardware. Because of this, generally we do not track problems with very specific hardware in qubes-issues, unless affect significant user base (popular hardware, affects a whole family of devices etc). Those more localized issues we prefer to discuss just on qubes-users ML. My main issue with this approach is lack of convenient method to get steps required to get Qubes working on a specific machine. Hardware Compatibility List serves as a place to get broad support status (works/doesn't work/something in between), but if any extra steps are needed, one needs to dig through (potentially lengthy) thread on a mailing list. Or multiple of them. It would be useful to have a convenient place for a summary of such thread(s), that can be easily updated. A wiki page perhaps (either in github or somewhere else)? This is IMO very similar to community documentation, so maybe some relation to https://github.com/Qubes-Community/ could work? Bugs in 3rd-party software generally we forward to upstream bug tracker and close in qubes-issues. But it is still helpful to track that upstream issue, especially when it affects some important function in Qubes (like recently salt issues in Fedora 32, affecting template updates[3]). Some issue trackers (bugzilla for example) have a feature of tracking external bug references, but not github. Note this is just about issue tracking, not necessary providing actual fixes - in many cases we do help upstream projects fixing issues that affect Qubes. Bugs that are not diagnosed enough to be actionable also noticeable part of github-issues. This makes it harder to find issues that can be worked on. ## Specific questions/ideas ## I think some of the above problems can be solved with combination of more labels ("more-info-needed"? "diagnosed"? using more "help wanted"?) and some predefined filters. Filters like "show bugs affecting current stable release that have all the info required to fix it", or "show features planned for the next release". While preparing such filters isn't really hard, I have no idea how to make them discoverable and easy to use. Any ideas? Also, maybe someone have some ideas for better labels that would allow easier filtering? For example I find priorities label hard to use, because it doesn't allow listing for example "issues with priority major or higher". There is also "projects" feature on github. Some of us use it for medium size task groups (too big for a single issue, but still small enough to not result in unusable long list). But I'm not sure if it helps with anything I mentioned in this email. [1] https://github.com/QubesOS/qubes-issues/issues/5863 [2] https://github.com/QubesOS/qubes-issues/issues/5875 [3] https://github.com/QubesOS/qubes-issues/issues/5791 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7YbdYACgkQ24/THMrX 1ywccQf+Oy7RLrabqM1yFenv/BMaJL/vplmsx3NkRXmhLkoij0Z1tapKz7si2QDS FcCNs9eM7JViOrFO9JvOXxlAYreor05vTHWrIiWHTymMx78ryZ/AXbhA2ZThdL5g ebmI5aqpc6t5Ras0lzweZNc60Cc20vJjiEFNq+jBYpoZnwAo85fTcC2nXTVQePQH pb2gVp+c9zZqkacFWQv8/9INQ0/uMEk6Ig4mBBhhtqvD9q1Ong9x6HWToD2QtrLM ftN8i4EWkQ7fVRw1RE0DBm5SrussWHI43sFbKIuf5dUiH3FPwRLYZpiZZ8wCz1oP gJoj4TCyye/FM4A1bewUgCdWVGMDXQ== =+ogv -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200604034317.GF6329%40mail-itl.
