On Jul 15, 2007, at 04:44, Juan Manuel Palacios wrote:
-) Expected: for most reports on port build failures, users are free to *expect* these to be fixed;
I always felt this name was odd. To me, it implies a sort of indifference to the bug: "we expect it'll get fixed sooner or later."
Colloquy's Trac simply defines these as "highest", "high", "normal", "low", "lowest" (defaulting of course to "normal"). This seems much clearer and perhaps more useful than our current system.
I agree with Ryan and you here, but then with Ryan again: I think "high", "normal" and "low" should suffice for most (if not all) our needs, while also sticking to self-explanatory names (I didn't write the current priorities, I also said "wha...?" when first becoming acquainted with our trac installation ;-). When you have both "highest" and "high", how is what's put in each determined? We want to keep this as simple as possible (but not one bit simpler, as Albert once said).
So I'll see about creating the new priorities and what will happen to existing tickets with the priorities I'll delete. We can later on add highest and lowest if need be, but I would discourage that.
Related: I'm not sure why we have both a priority and a severity. I'd say we only need one or the other, not both.
Feature Requests => Base Enhancements Base Bugs (currently missing?)
We currently have three milestones meant to group ticket submissions against MacPorts sources:
1) MacPorts x.y: release specific, where stuff that has been agreed to be worked on for the x.y release should go. I think this milestone is clearly defined. 2) Needs developer review: tickets detailing either bugs that can't be reproduced or with no agreed on fix, or enhancements/new features that spark controversy. They can be moved to the release specific milestone once consensus is reached *and* a committer agrees to stand behind it to do the leg work. I think this milestone is also clearly defined, but the protocol to get tickets out of it might be a bit flaky and therefore loosely enforced, suggestions accepted. 3) Feature Requests: I agree we need to refine this. I like the "Base Enhancement" & "Base Bugs" idea to group tickets against MacPorts sources that spark no controversy (that is, not in "Needs developer review") but have no man power to do the leg work (so as to keep the release specific milestones clean of stuff that will simply gather dust). Two problems I have with the proposed approach, though: I'd really love it if we could group these two fine ideas in just a single milestone (simplicity is golden!) that conveys the idea of "Will be worked on later"; and based on that, I'd like to use a name other than "Base", as some users are likely to not know what that means. Can you help me come up with a suitable name? I'm a bit sleepy already ;-)
I think the appropriate word would be "infrastructure." I still have a problem with "MacPorts x.y", "Feature Requests" and "Needs developer review". To be analogous with what we have for ports, we should have "Infrastructure Bugs" and "Infrastructure Enhancements". These would cover both bugs and enhancements that need developer review and those that don't. Do we really need a separate "Needs developer review" milestone? The "MacPorts x.y" milestones also give me problems because I don't think the person reporting the bug is in a good position to determine what version of MacPorts their bug should be assigned to be fixed in. We need to decide if we're using "Milestone" as a milestone or as a category. We seem to be moving to using it as a category, in which case "MacPorts x.y" categories don't make sense to me. Unless it is for use by developers who have just fixed something, to indicate what version of MacPorts they fixed it in. But that seems to be overloading this select box with two meanings, which I don't like.
*) Version: fine as it is now, but maybe a good addition is explaining that this field is irrelevant in some cases (like when filing tickets for the guide), whereas it's crucial in some others (a bug report against MacPorts sources);
A possible improvement, although more work, would be to add "release" as the new default, and "trunk". When tagging 1.5.1, the "release" version would be renamed "1.5.0" and a new "release" version created.
I don't think I fully understand what you're suggesting. Only two versions? We should definitely encourage users to always upgrade to the latest release 'cause we haven't broken backwards compatibility or anything, so no need to keep anyone back; even more now after my dp2mp-move work, which changed so many strings and paths and therefore might make debugging older versions harder. To that effect, I've removed all versions up to 1.5.0 and included 1.6.0 to stay always on "release" and "trunk".
But but but but but... Oh, I see. You can only select 1.5.0 and 1.6.0 for new tickets, but existing tickets that used earlier versions still show those versions. This is good. I wouldn't want to lose this information. I still don't think it's a good idea to remove any of the older versions, though. Definitely keep the 1.4.x versions, since 1.5. was *just* released and people who aren't in the habit of running selfupdate all the time will still be running 1.4.x. And if they run into a problem -- perhaps even with the update to 1.5.0 -- they'll want to file a bug, and either won't, because their version isn't in the menu, and then we won't learn about the problem, or they will, but will (by necessity) select the wrong version, which will in turn confuse us.