TL;DR: thank you for your suggestions and criticisms; new propositions in a separate message.
Le 13/10/2015 02:20, Scott Kostyshak a écrit :
If we do decide to get rid of the 2.2.x milestone, it is easy to do, rather than if we change our mind from getting rid of it to keeping it.
Yes, thank you for the work.
I agree with you. Although what Liviu says about people maybe saying "hmmm maybe I'll take a look in the 2.2.x milestone to find something to work on" would be nice, I don't see that happening.
On this aspect I can see it working well with either system, given that the relevant list would be added to the front page in any case. Le 13/10/2015 07:24, Pavel Sanda a écrit :
z.y.x milestone used to mean that it would be nice to have this bug fixed within z.y stable cycle (e.g. it does not involve fileformat change, does not need too much refactoring), but it's not happeninng in z.y.next_stable for whatever reason (during the cycle it usually starts to be dump for zombies).
Thanks for this explanation, Pavel.
I remember putting the remark about low priority in FAQ.
Here's all I could find about "enhancement" or "priority" on Trac, the website, the wiki and the repository (with git grep): “Enhancements have low priority and minor severity by default. We use 'Severity' field to determine urgency of the bugs.” This is quite different from “we hijacked the priority field to show enhancement in light blue”! I am sure it can be improved.
There was a time when I was sorting out every and each bug, finding dupes, contacting people who could be in charge etc. so while the usage of prio field was not intuitive it was consistent.
Now that I realize all that triaging effort that has been done and not just to mean that enhancements are by principle of lesser importance, I am more careful with refocusing the priority field. Of course you are right that one should not invalidate extant information and ingrained conventions. And thank you for this past effort.
No matter what system you come up with, people will break it. At the end what matters is comittment of one or few people continuously sorting out new entries. So while I do not have strong opinions about the suggestions or new system you might come up with, my concern is whether it's you who volunteer to keep trac in that state for next year or two ;)
I am surely not going to ensure that conventions are enforced neither in two weeks nor in two years. Le 13/10/2015 09:10, Liviu Andronic a écrit :
it may be something that works well enough and requires only some minor tweaks. Maybe we just need to document it explicitly for incoming devels...
Yes, if it only requires some minor tweaks that's great! But I still haven't got a non-contradictory explanation of what the current system is, although the picture is a bit clearer now. And we started with the concrete question of what to do with unmet milestones that we still have to address.
While I'm personally always very fond of my pet enhancement requests (and I'd be all for putting 'em all up in red)
I've had a look at the ~40 tickets I have currently bookmarked and I have to disagree, it is easy to compare them in terms of cost-benefit ratio and some tickets do stand out. There's always some part of subjectiveness, but at some point you have to assume that people are of good faith.
the hard truth is that our manpower is limited and our devels barely have the bandwidth to address crashes, regressions and the like (in between monitoring tickets, triaging, helping on the MLs, and implementing things sorely needed to keep up with software developments or just implementing things they need themselves). All those red color-coded tickets on Trac tend to focus spirits and keep devels around the bugs that absolutely need to get fixed until the next release.
I already did all of what you describe in addition to implementing long-standing feature requests and last-minute fixes of compilation; I am not going to take an authoritative argument about what I need. But, thank you for all your efforts at explaining the current conventions which are still a bit of a mystery to me. Guillaume
