-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Aug 09, 2023 at 03:36:03PM +0200, jmake2 via qubes-devel wrote: > I think that the new tag/milestone system is way better and logical, well > done. And arguments are quite convincing to me. > > I would like to add an idea about official templates. We know that there are > bugs in the templates, including the latest one fedora-38 or > fedora-38-minimal. Maybe you can consider tags (labels) in the same manner as > with released, e.g.: `affects-f37`, `affects-f38`, `affects-f38min`, > `affects-d11` (for Debian) and etc. > The reason - bug or problem in the official template is the same for R4.1 and > R4.2 (or am I wrong?) and, thus, is not a release-version-depended bug.
Generally, we don't track non-qubes bugs in our tracker (there are exceptions, but still). And qubes packages are specific to qubes release in most cases (so, a fix in one release doesn't make it automatically fixed in another). So, such label would still need to be combined with affects-4.1 or similar. We also have "C: Fedora"/"C: Debian" labels which serve similar purpose (but without specific version). So, generally an issue that would affect just a single version of a template (for example f37 but not f38) is either: - an issue in a software [version] specific to that template, not to qubes - in which case it should be tracked in that distribution tracker - a compatibility issue in qubes package connected with specific template version (like, some qubes package misbehave when using libfoo version 2.0, but works fine with version 1.0) The latter case might warrant label specific to template version, but would still require also a label specific to qubes version. It might be useful for testing template versions (like debian-12 right now), but in that case we encourage to simply mention template-tracking issue, so it gets linked by github. As for bugs affecting only older template versions but not newer (so, they stop being relevant when said template goes EOL), I have an impression those are rare, but maybe I'm wrong? Andrew, do you think it's worth it? > When new release of official fedora template comes out it changes the > situation every time: some new bugs are introduced, some are fixed without > afford of the Team by Fedora/Debian guys. Tracking this could be useful. > > Templates also have EOL, which could lead to closing outdated inactive > tickets in the same manner as with `affected-4.0` tags. And template's EOL is > not directly connected to Qubes OS version but more with Fedora project and > their EOL rules. > > > -- > Best regards, > jamke > > > > Aug 9, 2023, 06:06 by a...@qubes-os.org: > > > ## Summary > > > > Issues will no longer be assigned to milestones by default. Most issues > > won't have milestones. The Qubes developers will manually assign issues to > > milestones. We'll use labels like "affects-4.1" and "affects-4.2" to > > represent affected releases instead of milestones. The "Release TBD" and > > "Non-release" milestones are being phased out, as are milestones of the > > form "Release X.Y updates." Read on for a more detailed explanation. > > > > ## How milestones work right now > > > > Currently, our milestone guidelines are as follows: > > > > - Every issue should be assigned to *exactly one* milestone. > > - For *bug reports*, the milestone designates the *earliest supported > > release* in which that bug is believed to exist. > > - For *enhancements* and *tasks*, the milestone indicates that the goal is > > to implement or do that thing *in* or *for* that release. > > > > For example, if you were to report a bug that affects both 4.1 and 4.2 > > right now, it would be assigned to the "Release 4.1 updates" milestone, > > because 4.1 is the earliest supported release that the bug is believed to > > affect. As another example, if you were to open an enhancement issue right > > now, it would most likely be assigned to the "Release TBD" milestone, which > > means something like, "This enhancement, if it is ever implemented, will be > > implement in some Qubes release or other, but it has not yet been > > determined which specific Qubes release that will be." If it were decided > > that this enhancement would be implemented for 4.2, for example, then the > > issue's milestone would be changed to "Release 4.2." > > > > ## Problems with the current system > > > > Some people find our current use of milestones to be counterintuitive. For > > example, suppose that a bug is reported that affects both 4.1 and 4.2. The > > Qubes devs decide that it's not too serious, so it's okay just to fix it in > > 4.2 and leave it be in 4.1. Some people have the intuition that the issue > > should be reassigned to the 4.2 milestone, since the devs just decided > > that's where it'll be fixed. However, under the current rules, that would > > be wrong, since the bug still affects 4.1, and 4.1 is the earliest affected > > supported release. > > > > Similarly, suppose that someone reported a bug against 4.0, but it's one of > > those "we'll get around to fixing it someday, maybe" sort of bugs. Some > > people would be tempted to assign this issue to the "Release TBD" milestone > > on the grounds that the plan is to fix it at some yet-to-be-determined > > point in the distant future. However, this would again be wrong under the > > current rules, since the milestone for a bug report is supposed to > > represent the earliest supported release in which the bug is believed to > > exist, which is 4.0. > > > > The current method also presents problems when it comes time to close old > > issues. As many of you have probably noticed, I recently closed a large > > number of issues that were on the "Release 4.0 updates" milestone, since > > 4.0 reached EOL over one year ago, and those issues had not seen any > > activity in over a year. The problem arises when an issue affects more than > > one release. For example, there were some issues that affected both 4.0 and > > 4.1. In accordance with our milestone rules, those issues were assigned to > > the 4.0 milestone. When it came time to bulk-close the old 4.0 issues, > > issues were closed even though they also affect 4.1, which is still > > supported. The fact that those issues also affect 4.1 wasn't represented in > > a label or milestone (just in a free-text comment), so I had no way to > > filter them out when performing the bulk close action. > > > > Finally, each milestone has a progress indicator that shows the percentage > > of completed issues on that milestone, but this indicator isn't very useful > > when every issue that affects a given release gets assigned to that > > milestone, regardless of whether the devs actually plan to act on it. When > > every release ships with a partially-completed milestone, it becomes an > > unreliable indicator. > > > > ## Analyzing the nature of milestones > > > > Let's step back for a moment and think about what milestones are and what > > purpose they're supposed to serve. An issue tracking system doesn't > > actually *have* to have milestones at all. They're an optional feature. All > > an issue tracking system really needs is a single type of "tag" > > functionality (what GitHub calls "labels"). You can re-create almost any > > other type of issue tracking functionality (including milestones) with just > > tags. From this perspective, GitHub's milestones are basically the same as > > labels, except for two distinctive features: > > > > - Unlike labels, milestones are mutually exclusive. An issue can have an > > unlimited number of labels, but it can be assigned to at most one milestone. > > - Unlike labels, milestones have progress indicators. > > > > So, if we're going to use milestones, it makes sense to use them in a way > > that takes advantage of these distinctive features. > > > > ## How we plan to use milestones going forward > > > > Issues will no longer immediately be assigned to milestones. Instead, when > > the Qubes developers decide that they (or a contributor) will complete an > > issue for a certain release, they will assign that issue to the > > corresponding release milestone. This means that most issues won't be on a > > milestone at all. Instead of "every issue is on some milestone" as the > > default, it will be "no issue is on a milestone by default." Instead of > > each milestone containing all issues that are relevant to it, each > > milestone will contain a hand-picked selection of issues on which an > > authority has decided action will be taken for a specific Qubes release. > > > > We believe that this "curated list" approach to milestones will make them > > much more useful. With the current "kitchen sink" approach of each > > milestone containing every bug report ever filed for that release, each > > milestone contains many issues that the Qubes devs haven't even had time to > > diagnose. With the new approach, you can be confident that the Qubes devs > > have not only looked at and considered each issue in a given milestones; > > they've actually decided that action will be taken on that issue and plan > > for it to be done for that release! (Of course, the Qubes devs reserve the > > right to modify or remove milestones at any point at their discretion. > > Assigning an issue to a milestone isn't a binding commitment of any kind, > > and the realities of the software development process guarantee that > > milestone assignments will often change.) > > > > A side benefit of this new system is that it makes it clearer that every > > issue opened is merely "under consideration" until the Qubes developers > > approve of it and decide to act on it. (Even under the old system, > > assigning a bug report to the "Release 4.1. updates" milestone, for > > example, doesn't mean the Qubes developers plan to act on it or even that > > they agree that it's really a bug in 4.1.) > > > > Since we will no longer be using milestones to represent which release(s) a > > bug affects, we'll instead use labels like "affects-4.1" and "affects-4.2." > > This will allow us to accurately track cases in which a bug affects > > multiple releases. (I expect that "affects-*" labels will be used mostly > > with bug reports, but there are probably some cases in which they can > > sensibly apply to tasks and enhancements.) > > > > We currently have a milestone called "Non-release," which is for issues > > that are independent of the Qubes OS release cycle, such as website, > > documentation, and project management issues. This milestone provides > > little value and will be phased out. The main reason it existed under the > > old system is to satisfy the "every issue must be assigned to a milestone" > > rule, but it's actually redundant with labels like "C: doc." > > > > Similarly, we currently have the "Release TBD" milestone, which is for > > enhancements and tasks that will (or would) be specific to a Qubes OS > > release but have yet to be assigned to a specific release milestone. This > > milestone makes no sense under the new system, as *every* issue is in this > > state by default until it is hand-selected for inclusion in a specific > > release milestone. > > > > Finally, we have milestones like "Release 4.1 updates" (as opposed to just > > "Release 4.1"). Under the old system, these "* updates" milestones were > > used to collect issues (mostly bug reports) that were filed after the > > corresponding stable version was released (in this case, 4.1). In other > > words, all 4.1 bugs reported during the testing stages were assigned to > > "Release 4.1," then the stable 4.1 release was announced, the "Release 4.1" > > milestone was closed, and the "Release 4.1 updates" milestone was opened in > > its place. (In practice, it was already open by this point.) All "Release > > 4.1" bug reports that were still open and all subsequent 4.1 bug reports > > from that point onward were assigned to this "Release 4.1 updates" > > milestone instead. (In some cases, some bugs that the devs knew they > > wouldn't fix in time for the 4.1 release might've been assigned to "Release > > 4.1 updates" early.) Not only is this process confusing to newcomers > > (because the distinction between "Release 4.1" and "Release 4.1 updates" is > > too subtle); it also renders the progress indicator on the "Release 4.1 > > updates" milestone fairly meaningless, as it is attempting to track > > progress on updating a version that has already been released, which is a > > never-ending process until that release reaches EOL. These "* updates" > > milestones are also being phased out. > > > > Thanks for reading! To view the latest milestone guidelines at any given > > time, please see: https://www.qubes-os.org/doc/issue-tracking/#milestones > > > > -- > > 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 qubes-devel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/qubes-devel/6987bd94-817c-f216-e923-0d3029723f43%40qubes-os.org. > > > > -- > 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 qubes-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/NbPVjTN--3-9%40tutanota.com. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTTnwUACgkQ24/THMrX 1yzpSwf+OvC4uOCQjLKsOZyzAVPGpoDkzizF0NScXodGysRxfjnrUlK4DbLGZ/Uz lHfCZjshDP19YjTaGBMtFx0+5LZVtUsn/LufbpSTQAFZ3eInnyI3ggIuuSW5Ru1m 4n29/t147A+RmMQn2TL4z8hP7DDSyYGdxqLIE26/IvukWrfvAlBQPlMIov1FRf4D lHloo7LmNQFa19flf6yoCluRPrP1OLjQyh71+KsGnWlR1f+eZ4tLBiINrv3Sb9zd mcqBgsEkTtFtATbLYDSP7zJMkef5WrLOcZkoeMpwk2YBTwpPW+EC3wYzm635wcby hc3ZGqBAVv4CPG5HTs+8dfy03DOj0A== =gHO0 -----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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZNOfBTfiAXP0oONo%40mail-itl.
