On May 22, 2012, at 12:17 AM, Tomasz Finc wrote:
We tried the milestones and they were worse then
tracking bugs.
Sharing urls like this
https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=--…
vs
https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
could save the search but then its only available to you. Quickly
seeing what's resolved/blocking your release without having to go back
to advanced search is key.
The findability of such url is important, but the length or prettyness should
imho not be a factor. One could even argue that the longer one is actually more
usable because it contains the relevant product and version (rather than a
seemingly arbitrary bug ID) - and makes it possible to manipulate or construct
the url by hand (whether or not assisted by autocompletion in the address bar).
We can build portals, share bookmarks, create wiki pages with links, customize
the bugzilla sidebar, set links as default search for everybody and what not,
use shortcuts in mw-bot/wm-bot, shorten them with a url-shortener to a human
memorable url (e.g.
http://tinyurl.com/mw-12-open ). Lots of options for sharing.
Also, for MediaWiki core we're going more and more towards rolling releases.
Bugs and features will be scheduled and prioritized, but it is rare for
something to truly block a release. Sure we can schedule a feature for a
version, but if we don't make it, the release cycle will likely overrule the
feature implementation (or bug fix) and the bug is re-scheduled (depending on
why it wasn't done it will probably be moved to the next release, wontfixed
or perhaps left unscheduled until there is more interest or an assignee
available).
For myself I created a little portal to make working with our current workflow
easy (for MediaWiki core that is).
https://toolserver.org/~krinkle/wmfBugZillaPortal/
On May 22, 2012, at 4:05 AM, Yuvi Panda wrote:
Also, Tracking bugs let us make comments about the
release itself, something that milestones don't.
Since we're going more towards rolling releases I don't think we really need
such a place for MediaWiki core releases. Meta-discussion about the use of
milestones in general doesn't belong there anyway. And neither does discussion
about the release process. So what kind of discussion would take place on a
"MediaWiki 1.X.Y release (tracking)" bug that shouldn't take place on
wikitech-l, mediawiki-l, [[mw:Talk:MediaWiki 1.X]] or some other place?
The milestones are just the schedule / planning for developers to work from.
For scouting BugZilla I think this would be the workflow that ops and developers
follow (for BugZilla).
Developers:
* Open bugs in components other than Wikimedia (i.e. MediaWiki core/extensions)
scheduled for the next deployment
-> Cross-component tracker bug for 1.20wmf4: open[1]
* Open bugs scheduled for the currently being developed release
-> MediaWiki Milestone: 1.20.0 release: open[2]
Ops:
* General tasks for the current deployment (this list should be empty by the
time deployment happens, but if things brake after deployment that need fixing
right now, those bugs would be scheduled for the current deployment)
-> Wikimedia Milestone: 1.20wmf3: open[3]
* General tasks that need to happen before or at the next deployment window
(this list has to be empty before deployment. Anything on there either needs to
be done or re-evaluated)
-> Wikimedia Milestone: 1.20wmf4: open[4]
I'm curious whether other developers / ops also work (or would like to work)
like this though, and if not, what queries you use a lot. For example, another
way would be to work solely from searches like "Assigned to me" and rely on
someone else to use above queries and make sure everything high up, that isn't
fixed or assigned, gets assigned or lowered in priority.
-- Krinkle
[1] [2] [3] [4] These are all linked from
https://toolserver.org/~krinkle/wmfBugZillaPortal/
[1]
https://bugzilla.wikimedia.org/showdependencytree.cgi?hide_resolved=1
[2]
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=…
[3]
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=…
[4]
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=…