On Tue, May 22, 2012 at 2:05 AM, Krinkle <krinklem...@gmail.com> wrote: > 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=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App >> >> 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).
Yes, but having email readers do word wrap and truncation on URLs sucks. Saved searches would be ideal, but someone (maybe someone here!) needs to implement public saved searches: https://bugzilla.mozilla.org/show_bug.cgi?id=400063 It would be really great if we could coerce Bugzilla into behaving more like Redmine when it comes to milestones ("target versions" in their lingo). For example, look at this bug: http://www.redmine.org/issues/6597 Note that the "target version" is a link to "2.1.0" (as of this writing). Clicking on that link, that gives me: http://www.redmine.org/versions/47 ^ That page gives me a well-organized list of issues that are potential blockers for that release. Now look at this: http://www.redmine.org/projects/redmine/roadmap That's all of their upcoming releases. You can see at a glance what is planned for the next release, and what hasn't yet been pegged to a particular release. Also, we can go back in time http://www.redmine.org/versions/40 ^ This view gives us something to possibly use for release notes. The bar charts don't do too much for me. I'm mainly looking at this as a reasonably uncluttered view of what is associated with what milestone. Note that there are links to the same data presented in the standard query interface. Bugzilla has all of the data to generate the release note style view, but someone with some Bugzilla hacking ability would need to write the extension. Or maybe we could write a MediaWiki extension that uses the BZ API to generate these views. The only kicker would be making sure we also make the links from the individual issues actually go to the nice views. > 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). I think I might be better about using milestones if the milestone that I was using was reliably there. The 1.20wmf* milestones don't appear to be there for MediaWiki (only Wikimedia). That makes milestone kinda useless for deployment planning purposes. I'm not paying attention to the milestones now because I can't trust the queries contain all of the information I need. I've been holding off until we hire our Bug Wrangler before making a fuss about this, but I imagine the next Bug Wrangler is going to want this ability. Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
