On 6/22/20, Jonas Hahnfeld <hah...@hahnjo.de> wrote: > In short, I'd like to propose that we replace the labels Fixed_x_y_z > with milestones x.y.z and use these to track which issues were fixed > for a particular release. This has the advantage of a) less labels > which makes the drop-downs more usable and b) the possibility to close > milestones. After all, we're not going to fix bugs in already released > versions and they don't need to be available for new issues.
Sounds good. I only have a few questions: - How do you plan to indicate backports? (Granted, this is a very limited subset.) - What would become the process of marking issues as Fixed/Verified? At what stage do we “close” them? (I’d like to make sure that anything that has been fixed on master will be double-checked once the next GUB release is out; marking the milestone as “closed” wouldn’t offer much granularity in that regard, would it?) - By the way if I understand you correctly, the milestone would be “closed” _prior_ to the release? Then how do we validate bugfixes? > we should disable notifications of the lilypond project for that time frame. OK. Cheers, -- V.