On 8/8/23 11:06 PM, Andrew David Wong wrote: > ## 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. > > [...]
Okay, after trying this new system for a while, I see that there are still some problems: 1. Milestones are still confusing. It's still not intuitive to some people what it means for an issue to be on a milestone and when an issue should be added to a milestone. 2. Adding issues to milestones doesn't fit into the dev workflow. For some devs, adding the issues they plan to do to a milestone doesn't come naturally. Others add issues to milestones before checking with the release manager. I often end up having to remove issues from milestones that aren't approved and having to add closed issues to milestones that should have been there. All of this tells me that the milestone system isn't working well. That's okay. If it doesn't come naturally, it shouldn't be forced. This system is designed to help the devs, so we should tailor it to their workflow rather than the other way around. 3. Milestones are too similar to `affects-*` labels. The intended distinction is: `affects-*` = affects that release. Milestone = plan to do for that release. The former seems to be a lot more intuitive for people than the latter. So, what should we do about it? I propose we just get rid of milestones. Stop using them completely. (Just because a feature exists doesn't mean we have to use it.) What will we lose if we stop using milestones? From my perspective, not much: 4. It would be harder for the general public to see "how much work remains" before a given release. However, given (2) above, milestones aren't accurately representing this in the first place, so there's no real loss here. 5. It would be harder for us to see which issues we have done for a given release. For example, I used a search of all completed issues on the 4.2 milestone since RC3 to come up with the list of changes between RC3 and RC4. But there are potentially better ways to handle this. For example, we could just have an additional label like `merged-for-4.2` or something, which might be more intuitively understandable. -- 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/680decf2-69bf-4b08-9550-52ad48d20fac%40qubes-os.org.
