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=a... [3] https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=a... [4] https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=a...