On Mon, Jul 2, 2012 at 8:37 AM, Niklas Laxström niklas.laxstrom@gmail.com wrote:

On 2 July 2012 17:55, Chad innocentkiller@gmail.com wrote:

...

On Mon, Jul 2, 2012 at 10:45 AM, Niklas Laxström niklas.laxstrom@gmail.com wrote:

...

I think the upstream keyword in bugzilla is useless. Can we replace it with a field which takes an url to the upstream bug report?

When I've filed an upstream but, I usually put it in the URL field. Does that not work?

If you can keep the keyword and URL in sync. Quick search [1] confirms my concerns. There seems to be only few cases where URL is used to indicate where the bug happens, so conflicts on there are rare. But the problem remains.

[1] https://bugzilla.wikimedia.org/buglist.cgi?keywords=upstream&columnlist=...

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@gmx.netwrote:

...

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.

It already unclear to me what setting this keyword implies: That the person setting the keyword should also take care of forwarding it to upstream? That the person is also responsible to keep it in sync? Or just wishful thinking that somebody else will hopefully do that?

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

I'm okay with state, but not at all with resolution code. From the reporters perspective the issue is not fixed when it is reported upstream. For example if our Gerrit is broken, the issue not resolved until a fix is applied in our installation.

+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@organicdesign.co.nz wrote:

I'm just wondering how to clone an extension for a particular branch... e.g. using Subversion I could do this:

svn co

http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_18/extensions/Check...

What's the equivalent git command to get that same version of the extension?

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

On 11 July 2012 14:16, Andre Klapper andre_klapper@gmx.net wrote:

...

KDE Bugzilla uses "RESOLVED UPSTREAM" for such cases, Mer Project uses "RESOLVED TRIAGEDUPSTREAM" for such cases.

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:

I'm okay with state, but not at all with resolution code. From the reporters perspective the issue is not fixed when it is reported upstream. For example if our Gerrit is broken, the issue not resolved until a fix is applied in our installation.

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