On Mon, Jul 2, 2012 at 8:37 AM, Niklas Laxström <niklas.laxstrom(a)gmail.com> wrote: I've dabbled with the idea of turning "upstream" into a state, actually, since the state is often inconsistent (sometimes it stays open, sometimes its "resolved/later"), and it's not entirely clear what it should be. Another solution would be a resolution code (e.g. "resolved/filed-upstream") Barring any changes like that, I'd prefer to keep the keyword, and ask that the new Bug Wrangler help keep the upstream keyword up-to-date. For issues that do have the keyword, it's handy shorthand that has saved me some time parsing out the comments. Rob

On Wed, Jul 11, 2012 at 7:16 AM, Andre Klapper <andre_klapper(a)gmx.net>wrote;wrote: I try to make sure I've at least filed or found a bug report in the upstream tracker, subscribed to it there, and referenced it on our bug when applying the 'upstream' keyword. There's not really a standard for where to put a link to the upstream, but you'll usually find them in either: * the URL link field in bugzilla * in a comment * very occasionally, in "related bugs" Since the URL link on the bug may be needed for a demonstration of the bug, just putting it in a comment is the most consistent thing to do I think. I also sometimes reference our bug on the upstream tracker, which a) says "hey MediaWiki/Wikipedia needs this fix pls!" and b) may encourage folks on that side to contact us if we forget to follow the bug. ;) If we have anything marked 'upstream' where we *don't* have a visible upstream bug report, we should fix those. :) I kinda like the idea of a resolution instead of a keyword, as that simplifies the question of what to resolve as (open? later? something else?) but the keyword works for now. This should be covered by a triage guide to be written. +1 -- brion

+1 I think that the state is the best way to go here. I think a state works significantly better than a keyword and also logically makes significantly more sense logically. "Why aren't you working on the bug?" "Look! It's state says Upstream." The above makes much more sense than: "Why aren't you working on the bug?" "Look! It has a keyword that says Upstream." Thank you, Derric Atzrott

On Wed, Jul 11, 2012 at 10:40 AM, Aran <aran(a)organicdesign.co.nz> wrote: You can use the -b option to 'git clone' to have it initially check out a particular branch, something like: git clone -b REL1_18 https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CheckUser.git This is pretty much the same as doing 'git clone' followed by 'git branch' However, the old release branches on extensions have not been migrated to git, so you won't be able to check out that particular version. If you need the old ones, you can still check them out from SVN. -- brion

I need to correct myself: Mer Bugzilla uses TRIAGEDUPSTREAM as a *state*, not as a resolution. Also, MeeGo Bugzilla uses "WAITINGFORUPSTREAM" as a state too. On Wed, 2012-07-11 at 17:11 +0300, Niklas Laxström wrote: Good point - somebody would have to reopen the ticket after the fix has been committed upstream to get it deployed downstream (=WMF). So instead of using a resolution, a status WAITINGFORUPSTREAM seems to make more sense. Once a fix is available upstream somebody needs to manually reset the bug report status to UNCONF | NEW | ASSIGNED. andre -- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/