Re: [Wikitech-l] Just noticed GitBlit
On Wed, Jun 5, 2013 at 9:49 PM, Tyler Romeo tylerro...@gmail.com wrote:
So when did we get this new repo browser? Looks pretty nice, but I should
note that all on-wiki gitweb links have now been broken.
I updated mediawiki.org's {{git file}} and {{git summary}}. I left
templates like {{gitweb}} unchanged because extension boilerplate like
{{WikimediaGitCheckout}} uses it for download this version/that snapshot,
and gitblit doesn't have an equivalent. But if
https://gerrit.wikimedia.org/r/gitweb is shut down then the templates
should be modified.
IMO {{WikimediaGitCheckout}}that template add a lot of verbiage to
Extension pages, and should just output a link to a
git.wikimedia.org/summary/ URL and a link to Help downloading an
extension. But I'm not familiar with its history.
--
=S Page software engineer on E3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New git-review lets you configure 'origin' as the gerrit remote
I agree it would be nice for our repos (or git-review setup steps) would have sane defaults instead of ones almost everyone will want to change to not be annoyed. -- View this message in context: http://wikimedia.7.x6.nabble.com/New-git-review-lets-you-configure-origin-as-the-gerrit-remote-tp5006182p5006586.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New git-review lets you configure 'origin' as the gerrit remote
On Thu, Jun 6, 2013 at 12:37 AM, Aaron Schulz aschulz4...@gmail.com wrote: I agree it would be nice for our repos (or git-review setup steps) would have sane defaults instead of ones almost everyone will want to change to not be annoyed. Setting defaultremote=origin in each repository's .gitreview file wouldn't work well. We'd need to fix git-review further, first. git-review expects the remote that is used for interacting with Gerrit to be using SSH. This is a bug, but it's easy to see how it arose: if the remote is named 'gerrit', it's not totally insane for git-review to assume that it created it, and since it only creates SSH remotes, this one must be, too, right? So what happens if you set defaultremote to 'origin', then clone the repository using https? Well, this: ~$ git clone https://gerrit.wikimedia.org/r/analytics/glass Cloning into 'glass'... ~$ cd glass ~/glass$ git review -s Problems encountered installing commit-msg hook The following command failed with exit code 1 scp -P None gerrit.wikimedia.org:hooks/commit-msg .git/hooks/commit-msg --- Bad port ' None' --- I'm not sure what the correct behavior should be. It's tempting to tell git-review to upgrade the remote to use SSH, but it's sneaky to change a read-only remote to pushable one. If the 'origin' points at another site altogether (like GitHub), it's even thornier. (If nothing else, though, the error message should be better.) So the current situation may in fact be optimal. By default, 'git-review' will use 'gerrit' as a remote name, which is fine, since it's not likely to exist. So newbies get the same experience as before: slightly odd, but not broken. And if you're a power user and know to configure ~/.config/git-review/git-review.conf to specify defaultremote=origin, then you just have to remember to clone Gerrit repositories using ssh://, which you're probably doing anyway. Note that if you do that, there's no need to migrate anything: ~$ git clone ssh://o...@gerrit.wikimedia.org:29418/analytics/glass.git Cloning into 'glass'... ~$ cd glass ~/glass$ git review -s (success; no output.) Ori ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New git-review lets you configure 'origin' as the gerrit remote
Le 06/06/13 00:45, Yuri Astrakhan a écrit : I wonder if origin should be made the default setting for gerrit - after all every new git clone automatically uses origin. The fewer surprise! moments devs have, the more productive we become. This is how I name my git remotes: For Gerrit based repos: gerrit : upstream Gerrit ssh (either Wikimedia hosted or third party) anonymous : upstream gerrit HTTPS wikimedia : Gerrit ssh url when we have a fork of a third party repo which already takes the 'gerrit' name So given a Gerrit repo hosted by a third party I will have: gerrit ssh://third party repo wikimedia ssh://our gerrit repo And doing git-review will let me interact with upstream. If I want to update our fork I just: git push wikimedia gerrit/master:master . For Github: On a forked repo: origin or upstream: the upstream repo hashar : my github fork To update my fork: git fetch origin git push hashar origin/master:master My own repo: github : name of my repo git push github mybranch That is fairly complicated though and I often have to do a git remote -v before doing any operation. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
Le 06/06/13 00:15, Andre Klapper a écrit : in December I mentioned the idea of having a PATCH_AVAILABLE or PATCH_TO_REVIEW status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3]. snip Hello, Lamely copy pasting my reply to the December thread http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065047.html : ---8---8---8---8---8---8--- Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). ---8---8---8---8---8---8--- Which is essentially the same as PATCH_AVAILABLE and RELEASED. I never use the keywoard myself (I suck I crafting my own bugzilla searches). So I will more than welcome the status change. Make sure we can move straight from NEW to RELEASED. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Just noticed GitBlit
Le 06/06/13 06:49, Tyler Romeo a écrit : So when did we get this new repo browser? Looks pretty nice, but I should note that all on-wiki gitweb links have now been broken. For those wondering, Gitblit is a web frontend to git repositories. Chad has setup an instance at: https://git.wikimedia.org/ -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
Hi, On Thu, Jun 06, 2013 at 12:15:47AM +0200, Andre Klapper wrote: Hence I propose * [ drop patch-in-gerrit keyword ] * [ Add PATCH_AVAILABLE/PATCH_TO_REVIEW status ] I'd love to see that happening. :-) Best regards, Christian -- quelltextlich e.U. \\ Christian Aistleitner Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65aEmail: christ...@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax:+43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --- signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help with Scribunto/Lua modules
On Wed, Jun 5, 2013 at 8:22 PM, MZMcBride z...@mzmcbride.com wrote:
The debug console seems finicky. Its line numbers never seem to make
sense. For example, I input this into a fresh console:
The console isn't designed to handle blocks of code. You should compose
blocks of code into the module itself and use the debug console for simple
poking and prodding. You don't have to save the page: unsaved modifications
to the page are reflected to the console.
For example, go edit a module page, and paste this snippet into the code
editor:
--
local p = {}
function p.greet(name)
return Hello, .. name
end
return p
--
Then in the debug console, type:
=p.greet(Lua)
Hello, Lua
Lua error in console input at line 6: attempt to index local 'frame' (a
nil value).
That's because you wrote a function that accesses a frame parameter, but
you don't provide a value for it. You'll get a similar error if you omit
the name from the invocation of the 'greet' function we wrote earlier:
=p.greet()
Lua error at line 4: attempt to concatenate local 'name' (a nil value).
Note that the error cites the correct line number: it's indeed the 'return'
statement in p.greet that is causing the error. In some programming
languages, like Python, arguments without defaults are required, and it is
an error to omit them from the invocation. In Lua and some other languages
the value of any parameter that is absent from the invocation is set to
nil, so p.greet() is equivalent to p.greet(nil).
I have no idea what line 6 refers to. Earlier when I was testing it was
saying line 14. The line numbers never seem to match up to what I think
I'm testing.
I think your confusion resulted from trying to work with blocks of code in
the debug console.
frame can be a bit tricky to grasp and trickier still to work with, but
once you get it, it's not so bad.
The way Scribunto handles {{#invoke}} is this: first, it makes a table.
This is the 'frame' table. Then it makes an 'args' table inside that table.
Then it puts the arguments into the 'args' table. Then it calls your
function, passing the frame table as the sole parameter.
When the parser invokes a Lua function from an {{#invoke}}, it *always*
passes exactly one parameter: frame. It doesn't matter what arguments (if
any) were present in {{#invoke}} or what your function thought it was
getting. It's getting a frame and it's going to like it.
As an example, here's Lua code that is (very roughly) equivalent to how
Scribunto would handle {{#invoke:Sort|asc|3|1|2}}
--
frame = {}
frame.args = { 3, 1, 2 }
sort = require('Module:Sort')
sort.asc(frame)
--
This is a bit annoying, because at first glance invoke looks like it's
just an alternate syntax for a Lua function invocation, so you expect
{{#invoke:Sort|asc|3|1|2}} to be equivalent to sort.asc(3, 1, 2), but
that's not the case.
So, how do we work with this? I can recommend two approaches. For the
purpose of demonstrating them, let's imagine we want to write a Scribunto
math module that has a function, 'sum', that takes two numbers and adds
them. One approach is work with a frame parameter from the get-go.
--
local p = {}
function p.sum(frame)
return frame.args[1] + frame.args[2]
end
return p
--
This works if we save it and then try to invoke it from somewhere:
{{#invoke:Math|sum|4|5}} should evaluate to 9. But how do we test it in the
debug console? We'll pretend we're the parser and make our own frame table.
Paste the code block above into a module, and type this into the debug
console, hitting return after each line:
frame = {}
frame.args = { 4, 5 }
=p.sum(frame)
With any luck, you'll get '9'. You can make this shorter by creating both
tables at once:
frame = { args = { 4, 5 } }
=p.sum(frame)
Or even:
=p.sum({ args = {4, 5} })
Because calling a function with a table as the parameter is very common,
Lua has a special syntax for it, which lets you omit the parentheses:
=p.sum{ args = { 4, 5 } }
All of the variants above are equivalent.
The second approach is to not deal with frames until you have to. This
workflow works especially well when you're developing on your own computer,
using the standard Lua interpreter. Just write a normal Lua function and
verify that it works.
--
local p = {}
function p.sum(a, b)
return a + b
end
return p
--
You can test that it works with =p.sum(4, 5). When you're ready to save
your module, write a helper function that takes a frame table and uses it
to call your actual function.
--
local p = {}
function p.sum_real(a, b)
return a + b
end
function p.sum(frame)
return p.sum_real(frame.args[1], frame.args[2])
end
return p
--
This lets you test your function easily from the console, using 'sum_real':
=p.sum_real(4,5)
9
But 'sum' works from wikitext as expected: {{#invoke:Math|sum|4|5}} will
evaluate to 9.
There's a note on the edit screen about using mw.log(), but with various
inputs, I still can't seem to get anything working properly with the debug
console.
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
Antoine Musso hashar+...@free.fr wrote: in December I mentioned the idea of having a PATCH_AVAILABLE or PATCH_TO_REVIEW status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3]. snip Lamely copy pasting my reply to the December thread http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065047.html : ---8---8---8---8---8---8--- Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). ---8---8---8---8---8---8--- Which is essentially the same as PATCH_AVAILABLE and RELEASED. [...] Not quite: Fix Committed means the patch has been merged. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] [X-POST] Universal Language Selector(ULS) Deployment - Phase 1
On Wed, Jun 5, 2013 at 10:58 PM, Peter Coombe thewub.w...@googlemail.comwrote: What is the rationale for moving ULS from the personal toolbar to the interlanguage links on some sites? I find this change odd: * makes location and appearance of ULS inconsistent between sites * personal toolbar seems the conventional place for per-account settings and tools * features it is replacing like WebFonts live in the personal toolbar * interlanguage links are something rather different, taking the user to a wholly different site Thanks for asking, Peter. The options we considered are described in detail at https://www.mediawiki.org/wiki/Universal_Language_Selector/Design#Location_for_the_selector . When we tested the top-right position for language settings, it generated confusion for users on wikis with inter-language links. The top-right area was a new language-related area and they expected content language to be changed from there. We were never really satisfied with the UI elements that WebFonts and Narayam added, so those are implemented in Universal Language Selector. In short, depending on the context, language selection may have different purposes: * For contexts where the language of content can be modified, the language list will be shown by default, and the trigger will contain a list of likely languages. * For contexts where the content language cannot be modified, the settings view is provided instead as default. Since inter-language links are not being initially replaced by the language selector for monolingual wikis such as Wikipedia, the Universal Language selector will not be used to change content language. Cheers! Siebrand ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help with Scribunto/Lua modules
On Wed, Jun 5, 2013 at 11:22 PM, MZMcBride z...@mzmcbride.com wrote:
The debug console seems finicky. Its line numbers never seem to make
sense.
The debug console probably could use some work. The way it works now,
it takes your past and current input, plugs all that into some
boilerplate to make a function, and then executes that function. The
line numbers reported for Lua error in console input therefore
depend on this boilerplate and on the lines you've previously entered
in the session.
It's also possible to break that boilerplate function, as you've seen below.
For example, I input this into a fresh console:
---
function p.asc(frame)
return frame.args[1]
end
---
Then I try ...
= print(p.asc())
Lua error in console input at line 6: attempt to index local 'frame' (a
nil value).
I have no idea what line 6 refers to. Earlier when I was testing it was
saying line 14.
It's referring to which line in that boilerplate function the return
frame.args[1] ended up at. Yes, that's not extremely helpful.
If I paste this into the console:
---
[SNIP]
return p
---
I get Lua error in console input at line 18: 'end' expected (to close
'function' at line 1) near 'return'.
This is an example of breaking the boilerplate function. In Lua, it's
an error to have unreachable code after a return statement. When you
put return p into the debug console like that, the boilerplate
function winds up looking something like this:
function ( p )
local print = mw.log
-- Previous lines go here
mw.clearLogBuffer()
return p -- This is the line you entered
return nil, mw.getLogBuffer() -- This is boilerplate
end
Again, the console should probably be made more robust at some point
to avoid this sort of thing.
There's a note on the edit screen about using mw.log(), but with various
inputs, I still can't seem to get anything working properly with the debug
console. For example:
---
function p.asc(frame)
t = {}
t['bar'] = 'baz'
mw.log(t)
return frame.args[1]
end
---
This prints nothing at all when pasted into the debug console.
That's because you're defining a function but not calling it (yet).
If I try = print(t) or print(t) I get nil.
Since 't' is a local variable inside the function, it's not defined
outside of it.
Is there a var_dump equivalent for Lua that can be used?
Not yet.
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On Wed, 2013-06-05 at 21:54 -0400, Matthew Flaschen wrote: On 06/05/2013 08:18 PM, Daniel Friesen wrote: What is the workflow when: # Someone mentions the bug in a commit. # Gerrit Notification Bot changes the report status to PATHCH_TO_REVIEW # The patch is only related or only a partial fix and hence doesn't actually fix the bug. Yes, we need a separate Fixes-Bug: 123 annotation. When you use Fixes-Bug, you're saying When this is merged, it's fixed, rather than This is one step, or just somewhat related. Thanks a lot for pointing this out (this was also brought up when I discussed the idea with some folks at Amsterdam Hackathon, but I forgot to include it in my initial email). andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On Wed, 2013-06-05 at 15:29 -0700, Jon Robson wrote: I've been using ASSIGNED and assignee name to mean this... to me if someone is assigned to something it is a promise to attempt to fix it. Ideally I'd use ASSIGNED when seriously(TM) planning to work on a patch. I mean, seriously. But I know that there are small differences in interpretation out there, and whatever works for a developer or a development team also works for me. I'm not sure how patch to review would be useful... Gerrit should be the place to look for things to review - not bugzilla. I agree. This is more to minimize the small status mismatch we have to due to manual activity in Bugzilla (bug reports still open though patches have been merged which are supposed to fix the reports). A RELEASED would however would be useful. That's one of the next topics, see my PS at the bottom. :) andre On Wed, Jun 5, 2013 at 3:15 PM, Andre Klapper aklap...@wikimedia.org wrote: Hi everybody, in December I mentioned the idea of having a PATCH_AVAILABLE or PATCH_TO_REVIEW status in Bugzilla [1] and that we should re-evaluate the idea once we have automatic notifications from Gerrit into Bugzilla in place [2]. This is now the case [3]. From the Amsterdam Hackathon I know that some developers would like to filter on bug reports that have or don't have a patch in Gerrit, and easier finding of bug reports with a corresponding patch lack of recent changes might provide another entry point for new developers (pick up the existing patch and finish it). Hence I propose * to remove the manually set and error-prone Bugzilla keyword patch-in-gerrit: Every bug on its way to get RESOLVED FIXED has to pass this stage anyway so a status feels more appropriate, and * to make the Gerrit Notification Bot automatically change the bug report status to PATCH_AVAILABLE/PATCH_TO_REVIEW in Bugzilla when a patch for that bug report has been committed (not: merged) to Gerrit. Comments? andre [1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html [2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065226.html [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=17322 PS: Making the Gerrit notification bot automatically close bug reports in Bugzilla after merging a patch in Gerrit, or differentiating in Bugzilla between RESOLVED FIXED (fix merged) and RELEASED (fix deployed on the Wikimedia wikisites) are also interesting topics to discuss at some point, but not in this thread. One step at a time. -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
Salut, On Thu, 2013-06-06 at 11:25 +0200, Antoine Musso wrote: Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). ---8---8---8---8---8---8--- Which is essentially the same as PATCH_AVAILABLE and RELEASED. Yepp, and I like that. :) However, Bugzilla does not allow renaming RESOLVED FIXED (fix merged but not deployed), and I'm a bit concerned that changing the name would break a lot of Bugzilla query URLs out there. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On Thu, 2013-06-06 at 10:47 +1000, K. Peachey wrote: How does a Status change work better than a Keyword change in this case? It does not (assuming that the hooks-bugzilla plugin can do both status and keyword changes), I'm just combining two aspects in one go. :) A keyword (that I consider ideally a static attribute that should apply for the entire lifetime of a bug) just feels wrong for the usecase this bug has a patch committed. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help with Scribunto/Lua modules
On Thu, Jun 6, 2013 at 6:19 AM, Ori Livneh o...@wikimedia.org wrote:
This is a bit annoying, because at first glance invoke looks like it's
just an alternate syntax for a Lua function invocation, so you expect
{{#invoke:Sort|asc|3|1|2}} to be equivalent to sort.asc(3, 1, 2), but
that's not the case.
The problem there is what would {{#invoke:Module|func|foo=1|bar=2}} be
equivalent to? Maybe Module.func{ foo = 1, bar = 2}, but then your
earlier example would have to be sort.asc{ 3, 1, 2 }. And either case
your function would be getting a single table with the args as
parameters, which is only one step removed from the frame object you
actually do get.
Or, you might say, that it would somehow match up the foo and bar
with the parameter names in the function declaration. That would be
difficult to accomplish, would complicate modules that need a large
number of named parameters, and wouldn't allow for wikitext parameter
names that don't match the regex /^[a-zA-Z_][a-zA-Z0-9_]*$/.
Also, having the frame object allows for lazy parsing of the arg
values. As you probably already know, if a template argument is not
actually used inside the template, it never even gets expanded. The
same happens in Scribunto: the wikitext for an argument to #invoke is
not actually expanded until it is accessed in frame.args. We couldn't
do this if parameters to #invoke were passed directly as parameters to
the function.
We'll pretend we're the parser and make our own frame table.
Paste the code block above into a module, and type this into the debug
console, hitting return after each line:
frame = {}
frame.args = { 4, 5 }
Better would be to use the method specifically intended for this purpose:
frame = mw.getCurrentFrame():newChild{ args = { 4, 5 } }
That creates a real frame object, so you can test functions that need
the various frame methods (e.g. frame:expandTemplate) too.
You can even test things using frame:getParent().args with this method:
parentFrame = mw.getCurrentFrame():newChild{ args = { 'parent',
'template', 'args' } }
frame = parentFrame:newChild{ args = { '#invoke', 'args' } }
Note there is a limit on the number of child frames that can be
created, to avoid encouraging people to use this relatively-expensive
method in actual modules instead of passing arguments directly to
other Lua functions. If you hit this limit, just use the debug
console's Clear button.
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On 6 June 2013 15:40, Andre Klapper aklap...@wikimedia.org wrote: Salut, On Thu, 2013-06-06 at 11:25 +0200, Antoine Musso wrote: Launchpad.net has instead of RESOLVED and VERIFIED: Fix Committed (fixed but not available until next release) Fix Released (fix released). ---8---8---8---8---8---8--- Which is essentially the same as PATCH_AVAILABLE and RELEASED. Yepp, and I like that. :) However, Bugzilla does not allow renaming RESOLVED FIXED (fix merged but not deployed), and I'm a bit concerned that changing the name would break a lot of Bugzilla query URLs out there. As I understand it, the bug states we might want to capture are: [Existing UNCO/NEW/ASSI/REOP] * In gerrit but not merged - PATCH IN REVIEW (eww) or COMMITTED or whatever. * In gerrit and merged but not yet in production - RESOLVED/FIXED (confusing) or MERGED or whatever. Breaking queries' URLs would suck, though. * ? In production in /some/ places - not sure if we'd want to capture this, especially as we're hoping to move to continuous deployment anyway. * In production in all of the WMF cluster - RELEASED, replacing the unused VERIFIED state? * ? In a tarball release - maybe CLOSED could be used for this, but renamed? - WMF isn't the only user of MediaWiki, after all. Note that this ignores the state of merged-but-not-yet-fully-automatically-tested (:-() which I'd like to hope we don't have to deal with for much longer when we can finally merge in the cross-browser testing into gerrit's +2 gating. Also, +1 to a Fixes-Bug: 123 annotation or somesuch, as Timo proposed a couple of months ago in the rather more cryptic Bug 123 vs. Bug: 123. :-) J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Language Engineering office hour on 2013-06-12 at 17:00 UTC/10:00 PDT
Event Details # Date: 2013-06-12 # Time: 1700-1800 UTC, 1000-1100 PDT #IRC channel: #wikimedia-office on irc.freenode.net The Wikimedia Language Engineering team [1] invites everyone to join the team’s monthly office hour on June 12, 2013 (Wednesday) at 1700 UTC/1000 PDT in #wikimedia-office. During this session we would be talking about some our recent activities and updates from the ongoing projects. The provisional agenda is outlined below. See you all at the IRC office hour! Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation Agenda # Introductions # Universal Language Selector - Phase 1 deployment was on Tuesday 2013-06-11 [2,3,4] # Universal Language Selector - Phase 2 and later # Q/A - We shall be taking questions during the session. Questions can also be sent to siebrand at wikimedia dot org before the event, and will be addressed during the office hour. [1] http://wikimediafoundation.org/wiki/Language_Engineering_team [2] https://www.mediawiki.org/wiki/Universal_Language_Selector [3] https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ [4] https://www.mediawiki.org/wiki/Universal_Language_Selector/Design ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforres...@wikimedia.orgwrote: * In gerrit but not merged - PATCH IN REVIEW (eww) or COMMITTED or whatever. Committed would've been appropriate in Subversion, but 'committed' in Git does not guarantee it is available in Gerrit. On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforres...@wikimedia.org wrote: * In gerrit and merged but not yet in production - RESOLVED/FIXED (confusing) or MERGED or whatever. Breaking queries' URLs would suck, though. I agree, we shouldn't break existing URLs. Let's not rename existing ones. On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforres...@wikimedia.org wrote: * ? In production in /some/ places - not sure if we'd want to capture this, especially as we're hoping to move to continuous deployment anyway. * In production in all of the WMF cluster - RELEASED, replacing the unused VERIFIED state? This should definitely not be used for WMF cluster deployment, only for tarball releases to third parties (if at all). Also I'm not sure 'Verified' is completely unused... On Thu, Jun 6, 2013 at 4:05 PM, James Forrester jforres...@wikimedia.org wrote: Also, +1 to a Fixes-Bug: 123 annotation or somesuch, as Timo proposed a couple of months ago in the rather more cryptic Bug 123 vs. Bug: 123. +1 from me as well. Alex Monk ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
Hi, On Thu, Jun 06, 2013 at 04:39:41PM +0200, Andre Klapper wrote: assuming that the hooks-bugzilla plugin can do both status and keyword changes That assumption does not hold true: hooks-bugzilla can set the status, but it currently cannot set keywords, as j2bugzilla (underlying java-bugzilla connector) does not support it. However, adding that functionality is totally doable, if we settle for staying with keywords. (Which I hope we do not) Best regards, Christian -- quelltextlich e.U. \\ Christian Aistleitner Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65aEmail: christ...@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax:+43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --- signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Welcome to Ken Snider, Wikimedia Operations
Hello all, I’m delighted to announce that Ken Snider is joining the Wikimedia operations team. He will start as an international contractor working remotely from Toronto, Canada on June 10, and will be visiting SF in the week of June 17. We’re currently in the process of seeking work authorization in the United States in the Director of TechOps position. CT has graciously agreed to support the ops leadership transition full-time through June, and part-time through July. We’ll be starting the handover while Ken is working remotely. A bit more about Ken: Ken was apparently genetically predisposed to become a sysadmin since he joined one of Canada’s first large ISPs, Primus, straight out of school in 1997 and helped build their infrastructure til 2001. He then joined a startup called OpenCOLA in 2001 which was co-founded by Cory Doctorow and developed early P2P precursors to tools like BitTorrent and Steam. It’s best known today for the development of an open source (GPL’d) cola recipe which is still in use (more than 150,000 cans sold if Wikipedia is to be believed). Ken got involved in one of Cory’s pet projects, BoingBoing.net which some of you may have heard of ;-), and has been their sysadmin since 2003. After a stint from 2001-2005 at DataWire, Ken became Director of Tech Ops at Federated Media, a role he held from 2005-2012. Federated Media is an ad network that was founded to support high traffic blogs and sites that want to stay independent of large publishers, with a network that supports more than 1B requests/day. One of the unusual challenges at FM was that the company grew through acquisitions of various blogging and publishing networks. This led to the challenge of integrating very heterogeneous operations and engineering infrastructure, including multiple geographically distributed ops teams and data-center locations. As DTO, Ken led these efforts, such as OS standardization, development of a unified deployment infrastructure, etc. Ken also ensured that the operations group partnered effectively with the various engineering teams developing site features and enhancements. I want to again take this opportunity to thank CT Woo for his tireless operations leadership since December 2010. I’d also like to thank everyone who’s participated in the Director of TechOps search process. Please join me in welcoming Ken to the Wikimedia Foundation and the community. :-) All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On 6 June 2013 16:58, Christian Aistleitner christ...@quelltextlich.atwrote: However, adding that functionality is totally doable, if we settle for staying with keywords. (Which I hope we do not) I agree; keywords are meant to be time-invariant, not statuses; they're the wrong conceptual item to apply for temporary things like patch in gerrit. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome to Ken Snider, Wikimedia Operations
quote name=Erik Moeller date=2013-06-06 time=09:17:29 -0700 Hello all, I’m delighted to announce that Ken Snider is joining the Wikimedia operations team. Welcome Ken! Can't wait to start working with you! Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help with Scribunto/Lua modules
On Thu, Jun 6, 2013 at 10:23 AM, Brad Jorsch bjor...@wikimedia.org wrote: The debug console probably could use some work. The way it works now, it takes your past and current input, plugs all that into some boilerplate to make a function, and then executes that function. The line numbers reported for Lua error in console input therefore depend on this boilerplate and on the lines you've previously entered in the session. It's also possible to break that boilerplate function, as you've seen below. I agree. I know it's a stretch, but the ideal situation would be to have some sort of actual debugger. Like a full-blown console or something where you could test code and it would tell you where it failed and why, etc. I know some of this is supported already. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Just noticed GitBlit
On 06/06/13 07:21, Daniel Friesen wrote:
Side topic, anyone want to voice their bikeshed opinions on their
favorite the different ways of disambiguating a / inside urls for
various types of web UIs to repositories:
- Rejecting slash in repository names /.../mediawiki-core/... (ie:
GitHub :/)
- Urlencoding the slash /.../mediawiki%2Fcore/...
- Appending a .git to the end of the name /.../mediawiki/core.git/...
- Wrapping it in syntax/.../{mediawiki/core}/...
- Escaping it /.../mediawiki\/core/...
Accept the longest substring.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome to Ken Snider, Wikimedia Operations
On 06/06/13 18:17, Erik Moeller wrote: I want to again take this opportunity to thank CT Woo for his tireless operations leadership since December 2010. I’d also like to thank everyone who’s participated in the Director of TechOps search process. Since Dec 2010. Time flies! Welcome Ken! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help with Scribunto/Lua modules
On Wed, Jun 5, 2013 at 8:22 PM, MZMcBride z...@mzmcbride.com wrote: snip Is there a better way to write/debug Lua modules? Any help writing these modules (or simply getting a working sort module on Meta-Wiki) would be appreciated. I edited your code to make the Sort Module do what I think you intended it to do. -Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Questions
On Thu, Jun 6, 2013 at 6:56 PM, Tyler Romeo tylerro...@gmail.com wrote: Quick two questions: 1) Was that bug with E:CentralAuth that prevented us from turning on $wgSecureLogin ever fixed? If so, can we attempt another deployment? 2) I noticed something in the signpost: Walsh told the *Signpost* that while moving to an https default is a goal the WMF is actively working on, doing so is not trivial—it is a delicate process that the WMF plans to enable in graduated steps, from logged-in users to testing on smaller wikis before making it the default for anonymous users and readers on all projects. Is this at all true? Because from what I've been told on bug reports it seems like turning on HTTPS would indeed be a trivial step and that the operations team has confirmed we can do it at will. I also question the definition of actively working on. ;) You are misreading. What is being discussed is HTTPS by default for anonymous readers. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Questions
On Thu, Jun 6, 2013 at 7:10 PM, Ryan Lane rlan...@gmail.com wrote: You are misreading. What is being discussed is HTTPS by default for anonymous readers. Ah yes. I see now. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On 06/06/2013 11:16 AM, Alex Monk wrote: This should definitely not be used for WMF cluster deployment, only for tarball releases to third parties (if at all). Also I'm not sure 'Verified' is completely unused... I don't generally use it, but I've seen the QA/browser testing team do so. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
