On 8/9/23 6:36 AM, 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. > > 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 >
Good point! I agree; it makes sense to track whether a bug affects a specific template version independently of the Qubes OS release on which that template happens to be used, especially when that template is supported on multiple Qubes OS releases. (P.S. -- The convention on these mailing lists is to used interleaved or bottom-posting rather than top-posting.) > > 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/1ad02865-94f2-5aed-6ba9-d25da1436dcb%40qubes-os.org.
