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
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/