On 8/9/23 7:13 AM, Marek Marczykowski-Górecki wrote: > 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? >
Oh, my mistake. It sounds like templates are more Qubes-version-dependent than I realized. In that case, I think you're right that it may not be worth it, given we already track both Qubes release and general template type with existing labels. >> 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. > > -- 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/2654b783-f7ba-75d5-b918-4b55fc4fa551%40qubes-os.org.
