On Wed, 2012-11-28 at 00:36 +0100, Krinkle wrote:
I don't think adding more fields/values is the solution. Perhaps use milestone for "immediate"?
Currently milestones are used in "MediaWiki" for tarballs (that we don't create for MW 1.21), in "VisualEditor" for deployments (VE-2012-12-34), and globally in "MediaWiki Extensions" for branches refering to a MediaWiki version. See my last two lines down there in this email.
So both "Get man on the moon (tracking)" and "[Regression] Bike shed should not be on fire" have highest priority. But one is a regression milestoned for the current release, and the other is on track for N+2 release or maybe "Future release".
For the "MediaWiki" Bugzilla product: The conflict would be "wmf deployments" vs "MW tarballs". We currently use TMs for MW tarballs and we have a "1.20.x", "1.21.0" there. We tag regressions with a "code-update-regression" keyword. For issue that should block wmf deployments the blocker bug 38865 is used (which is not great but I plan to tackle this later, not now).
Besides an "immediate" bug without a milestone doesn't make sense to start with? If that is possible, there is a missing milestone I guess.
It's possible. Immediate means immediate. ;) If it should block wmf deployment, also mark it as blocking bug 38865. If it should block an MW tarball, set the Target Milestone accordingly.
We should make more use of being able to combine and query different fields to express clarity instead of adding more options that represent a multiple of values in other fields which then also need to be set separately
I agree in the long run, but it might interfere with teams and their use of Bugzilla again. Global workflows vs. "this works for my team". Right now I'd like to introduce a clear way to mark issues that should be handled immediately.
andre