Re: [Wikitech-l] Using wiki pages as databases
On Feb 20, 2013 at 3:54 pm, Tim Starling wrote: The idea of storing a database in a large string literal could be made to be fairly efficient and user-friendly if a helper module was written to do parsing and a binary search. I have implemented the above suggestion with some promising results. Packing a large table in a string and unpacking it on demand appears to work well, and the data is accessed as if it were stored in a standard table. Using the table from Wiktionary Module:Languages mentioned earlier in this thread, testing shows that accessing the packed data is 20 times faster. Info is at http://test2.wikipedia.org/wiki/User_talk:Johnuniq#Big_tables Johnuniq ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
Wonderful! So, now that we have a release manager for MediaWiki, is the release manager the person who writes/approves the policy for what sort of things are worth a 1.x.y release and how they're tracked on bugzilla, and will Chris be able to make and push tarballs for those even if they're not (only) security-related? Last news I have is that Chris was going to discuss said policy with RobLa (and maybe also Greg), but this looks superseded. I have a list of about a dozen (?) critical bugs in 1.20.2 that make me not so proud (and perhaps ashamed) of suggesting people to upgrade to it, at least for some use cases. Another thing that would be nice to have on https://www.mediawiki.org/wiki/Version_lifecycle or elsewhere is what are reasonable expectations about the stable releases. For instance, we know that 1.x.0 releases are always a nightmare: they're practically untested; branch point is pseudo-random and we have no info whatsoever about the bugs that MediaWiki (and extensions) had at any given revision. It would be nice to write somewhere that, say, 5 months after the 1.x.0 release came out, it's reasonable to think that most of its critical bugs/regressions are fixed in the last 1.x.y release; while of course 1.(x-1).* and 1.(x+1).* will have different bugs. Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 22 February 2013 12:03, Federico Leva (Nemo) nemow...@gmail.com wrote: Another thing that would be nice to have on https://www.mediawiki.org/wiki/Version_lifecycle or elsewhere is what are reasonable expectations about the stable releases. For instance, we know that 1.x.0 releases are always a nightmare: they're practically untested; branch point is pseudo-random and we have no info whatsoever about the bugs that MediaWiki (and extensions) had at any given revision. It would be nice to write somewhere that, say, 5 months after the 1.x.0 release came out, it's reasonable to think that most of its critical bugs/regressions are fixed in the last 1.x.y release; while of course 1.(x-1).* and 1.(x+1).* will have different bugs. Sounds LibreOffice-ish - they release a x.x.0 and schedule x.x.1 for a month after, with bug fixes, even if there's no security problems forcing a release. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using wiki pages as databases
On Fri, Feb 22, 2013 at 4:41 AM, Johnuniq wp.johnu...@gmail.com wrote: On Feb 20, 2013 at 3:54 pm, Tim Starling wrote: The idea of storing a database in a large string literal could be made to be fairly efficient and user-friendly if a helper module was written to do parsing and a binary search. I have implemented the above suggestion with some promising results. Packing a large table in a string and unpacking it on demand appears to work well, and the data is accessed as if it were stored in a standard table. Using the table from Wiktionary Module:Languages mentioned earlier in this thread, testing shows that accessing the packed data is 20 times faster. Info is at http://test2.wikipedia.org/wiki/User_talk:Johnuniq#Big_tables Note that https://gerrit.wikimedia.org/r/#/c/50299/ added a mw.loadData() function that should solve the problem for normal tables. It works like require, but can only handle simple data (no functions, tables with metatables, or tables with tables as keys), the returned data structure is made read-only, and it avoids having to re-execute the module chunk on every #invoke. Speaking of which, I need to update the documentation. -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] linking to wikidata pages
Two separate users on Commons complained that interproject links from Wikimedia Commons to Wikidata, like [[d:Q7186]] produce hyperlinks in form http://wikidata.org/wiki/Q35548; or http://en.wikidata.org/wiki/Q35548; which do not allow editing of wikidata. Only external link to http://www.wikidata.org/wiki/Q35548 leads to editable page. See http://commons.wikimedia.org/wiki/User_talk:Jarekt#a_small_modification_to_.7B.7BCreator.7D.7D and http://commons.wikimedia.org/wiki/Template_talk:Creator#Wikidata_hyperlink . I cannot reproduce those problems, since all 3 types of links seems to lead to editable pages for me. Did anybody on this list, know what might cause issues for those users. One clue might be that both use French as their native language. Any ideas? Jarek T. User:jarekt ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] linking to wikidata pages
On Fri, Feb 22, 2013 at 3:43 PM, Tuszynski, Jaroslaw W. jaroslaw.w.tuszyn...@saic.com wrote: Two separate users on Commons complained that interproject links from Wikimedia Commons to Wikidata, like [[d:Q7186]] produce hyperlinks in form http://wikidata.org/wiki/Q35548; or http://en.wikidata.org/wiki/Q35548; which do not allow editing of wikidata. Only external link to http://www.wikidata.org/wiki/Q35548 leads to editable page. See http://commons.wikimedia.org/wiki/User_talk:Jarekt#a_small_modification_to_.7B.7BCreator.7D.7D and http://commons.wikimedia.org/wiki/Template_talk:Creator#Wikidata_hyperlink . I cannot reproduce those problems, since all 3 types of links seems to lead to editable pages for me. Did anybody on this list, know what might cause issues for those users. One clue might be that both use French as their native language. Any ideas? It's a known problem, yes. The pages are editable but the edit doesn't actually save. It's one of the main pain points we have atm. Fix waiting for review and deployment by ops: https://gerrit.wikimedia.org/r/#/c/49069/ https://bugzilla.wikimedia.org/show_bug.cgi?id=45005 Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] linking to wikidata pages
On Fri, Feb 22, 2013 at 10:46 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Fri, Feb 22, 2013 at 3:43 PM, Tuszynski, Jaroslaw W. jaroslaw.w.tuszyn...@saic.com wrote: Two separate users on Commons complained that interproject links from Wikimedia Commons to Wikidata, like [[d:Q7186]] produce hyperlinks in form http://wikidata.org/wiki/Q35548; or http://en.wikidata.org/wiki/Q35548; which do not allow editing of wikidata. Only external link to http://www.wikidata.org/wiki/Q35548 leads to editable page. See http://commons.wikimedia.org/wiki/User_talk:Jarekt#a_small_modification_to_.7B.7BCreator.7D.7D and http://commons.wikimedia.org/wiki/Template_talk:Creator#Wikidata_hyperlink . I cannot reproduce those problems, since all 3 types of links seems to lead to editable pages for me. Did anybody on this list, know what might cause issues for those users. One clue might be that both use French as their native language. Any ideas? It's a known problem, yes. The pages are editable but the edit doesn't actually save. It's one of the main pain points we have atm. Fix waiting for review and deployment by ops: https://gerrit.wikimedia.org/r/#/c/49069/ https://bugzilla.wikimedia.org/show_bug.cgi?id=45005 Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l It seems like there's more than one problem here. Besides the things should redirect to canonical url: *Why are interwikis going to the non-canonical url. That seems like the interwiki map is misconfigured. We can make both commons: and wikidata: link to the proper url, why does d: have a lang subdomain? *Why do edits not work on the non-canonical url (is it because the api requests go to a fully qualified url based on $wgServer instead of of a relative url? Is there a reason for doing this?) -- - bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On 02/22/2013 03:42 AM, Thorsten Glaser wrote: I am a bit unhappy that instead of a database, MySQL is used/preferred, but (after the last few bugfixes), PostgreSQL works, so I’m set. Please do not hesitate to file any bugs for things that don't work for you in PG. And if they aren't getting resolved quickly enough, please ping me. I expect us (as in, my employer) to not follow every single MW release quickly, and Debian probably won’t either (most‐ ly for lack of manpower, I guess). And this is the exact reason that I initiated LTS support for 1.19. We'll make releases every 6 months, but you can be assured that we'll support 1.19 for a while. With my Debian Developer hat on, I don’t sense much in that area of complaints either. I installed the package last night on http://home.nichework.com/ -- dns may not be propagated yet -- and was disappointed that you didn't use the CLI installer to set up a wiki using debconf. There were a couple of other nits, but I think that overall it is a great thing. Thanks, Mark -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote: will Chris be able to make and push tarballs for those even if they're not (only) security-related? I can make and push tarballs without involving Chris. But yes, we need to discuss policy, and start setting expectations, etc. Can we build off the conversation you've started? That is, can you drive this conversation? Does anyone else have thoughts about Nemo's ideas for release expectations? -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 2-19 Bug Day Summary and a Question
We held our second bug day Tuesday Feb. 19th. *How it Went* We looked at open bugs in the Wikimedia's Git/Gerrit component. We focused on upstream issues that may have been fixed with the recent upgrade and issues that need status updates. Andre, ^demon, MatmaRex and I triaged bugs and had help from developers in #wikimedia-dev. *What we Achieved* We triaged about 25 bugs [1]. This included retesting old reports to see if the problem still exists after the Gerrit software upgrade on the Wikimedia server. Many of these bugs were still valid, so we checked statuses of upstream reports to see if some progress has taken place in the meantime *Improvements Implemented* -Better Landing Page [1] started as a landing page listing 'Who,' 'What,' 'When,' and 'Where.' Since we focused on upstream issues I was able to link to Release Notes and Gerrit's bug tracker on that page and not clutter up [2]. After the event we recorded the bugs that were acted upon and comments from the events etherpad onto the new page. We will likely continue this process. *Question for Prospective Participants* I would like to know if the timing may be a barrier for prospective attendees. Is there a better time to hold the bug days? So far we've run both events on a Tuesday 17:00-23:00 UTC. We could alternate the time we hold bug days to allow more people to participate. Again, thank you for your participation and support! -Valerie Juarez [1] http://www.mediawiki.org/wiki/Bug_management/Triage/20130219 [2] http://www.mediawiki.org/wiki/Bug_management/Triage ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Caching Discussion: Dealing with old (deleted) wmf branches
Hello all, Background and longer/more detailed discussion on this issue is in bug 44570: https://bugzilla.wikimedia.org/show_bug.cgi?id=44570 Summary: As we delete old -wmfX branches there appears to be cached pages that reference old branch URLs, eg: https://bits.wikimedia.org/static-1.21wmf1/skins/common/images/poweredby_mediawiki_88x31.png (that 404s because 1.21wmf1 is long gone) If you want to see my bad ASCII art representation of our current caching layers, see this page: http://wikitech.wikimedia.org/view/Caching_overview So possible ways forward option 1: * reduce parsercache timeout to size of deployment window (~28 days) [0] * Tim may have knowledge why that shouldn't happen [1] option 2: * change away from version numbers in URLs [2] ** maybe use slots or something else ** skins? option 3: * status quo What do you think? Greg [0] https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c14 [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c12 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c15 -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On Fri, Feb 22, 2013 at 8:24 AM, Mark A. Hershberger m...@everybody.org wrote: On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote: will Chris be able to make and push tarballs for those even if they're not (only) security-related? I can make and push tarballs without involving Chris. And further, I'm planning *not* to push tarballs unless they are security related (unless for some reason Mark needs me to help out on a particular release, which I'm always happy to do). But yes, we need to discuss policy, and start setting expectations, etc. Can we build off the conversation you've started? That is, can you drive this conversation? Does anyone else have thoughts about Nemo's ideas for release expectations? I don't have much to add, other than after the last security release, we've been planning to keep security and feature releases reasonably separate. This is so a user who only wants security patches doesn't have to find the security relevant parts of the patch. It also keeps changes to a minimum with security fixes, so it's less likely that an admin will need to revert the security fix if it breaks their install. But, this means more updates for users to install in general. Is that the preferred trade-off? Currently, all of our tools build the tarballs from the git REL branches, so keeping security releases entirely separate means we have to be more careful about what we push into that branch, to make sure it's always ready to have a release made if we need to do a security release. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 2013-02-22 2:37 PM, Chris Steipp cste...@wikimedia.org wrote: On Fri, Feb 22, 2013 at 8:24 AM, Mark A. Hershberger m...@everybody.org wrote: On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote: will Chris be able to make and push tarballs for those even if they're not (only) security-related? I can make and push tarballs without involving Chris. And further, I'm planning *not* to push tarballs unless they are security related (unless for some reason Mark needs me to help out on a particular release, which I'm always happy to do). But yes, we need to discuss policy, and start setting expectations, etc. Can we build off the conversation you've started? That is, can you drive this conversation? Does anyone else have thoughts about Nemo's ideas for release expectations? I don't have much to add, other than after the last security release, we've been planning to keep security and feature releases reasonably separate. This is so a user who only wants security patches doesn't have to find the security relevant parts of the patch. It also keeps changes to a minimum with security fixes, so it's less likely that an admin will need to revert the security fix if it breaks their install. But, this means more updates for users to install in general. Is that the preferred trade-off? Currently, all of our tools build the tarballs from the git REL branches, so keeping security releases entirely separate means we have to be more careful about what we push into that branch, to make sure it's always ready to have a release made if we need to do a security release. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I still would like to see critical bug fixes in next point releases including security releases. For example I would like to see the fix for the bug where wfSuppressWarnings turns on warnings that werent previously enabled, in php 5.4, instead of turning off the warnings to be included in the next point release. (Since the breakage is quite significant imo) I personally would also like to see up to date i18n files in every release regardless of type. Otherwise third parties will never see i18n fixes. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Deployment Highlights - 2013-02-22
This is your weekly preview of higher-risk or general you should be aware of items for the slew of deployments coming in the near term. During the week of March 11th: * Scibuntu (Lua) to all wikis * upgrades to DNS software/config for better reliability See the full Deployments page for regularly scheduled events and less high-risk items: https://wikitech.wikimedia.org/view/Deployments Best, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects. My preference for this would be to have a centralized wiki for identity urls. The identity urls would be based on user pages. I'm proposing this for a few reasons: 1. It's easier to deal with identity urls in a centralized location, and it allows us to avoid including the OpenID extension on every wiki 2. We could very strictly limit our vulnerability surface on this wiki by only including what's necessary 3. At a later point we could decide to limit all authentication to this location, pointing login links from all projects/wikis here 4. At a later point we could decide to also use this as a global profile location I'd prefer if we avoid the bikeshedding of the domain name in this discussion, if we are all in agreement over the use of a centralized wiki. Thoughts? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Is this up for discussion, or are we at the point of planning deployment? It isn't apparent to me why any WMF site would be an OpenID provider. maiki On 02/22/2013 11:33 AM, Ryan Lane wrote: I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects. My preference for this would be to have a centralized wiki for identity urls. The identity urls would be based on user pages. I'm proposing this for a few reasons: 1. It's easier to deal with identity urls in a centralized location, and it allows us to avoid including the OpenID extension on every wiki 2. We could very strictly limit our vulnerability surface on this wiki by only including what's necessary 3. At a later point we could decide to limit all authentication to this location, pointing login links from all projects/wikis here 4. At a later point we could decide to also use this as a global profile location I'd prefer if we avoid the bikeshedding of the domain name in this discussion, if we are all in agreement over the use of a centralized wiki. Thoughts? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Tip of the day: MediaWiki on Raspberry Pi: use APC to make it responsive
I run a bigger bleeding-edge-software MediaWiki via SSL on a Raspberry Pi. And that's not too slow because I use APC. My quick tip of the day # add APC (Alternative PHP Cache) # seehttps://www.mediawiki.org/wiki/Extension:APC # stop your web server service apache2 stop # Install APC apt-get install php-apc # download APC extension (it is a dashboard for APC and adds a Special page) cd $IP/extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/APC.git # in LocalSettings.php make sure to have the following lines ## Shared memory settings $wgMainCacheType= CACHE_ACCEL; $wgMemCachedServers = array(); # $wgGroupPermissions['apc']['apc'] = true; # or simply give the right to an existing trusted group, like bureaucrat: require_once($IP/extensions/APC/APC.php); $wgGroupPermissions['bureaucrat']['apc'] = true; # and restart your server service apache2 start signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Self-signed cert on https://wikitech.wikimedia.org/
Tested in Firefox and Chromium: wikitech.wikimedia.org uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_untrusted_issuer) FYI, nameless person who fixes that. ^_^ maiki ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
quote name=maiki date=2013-02-22 time=12:17:25 -0800 Is this up for discussion, or are we at the point of planning deployment? It isn't apparent to me why any WMF site would be an OpenID provider. To phrase this differently: Do you more prefer that WMF sites consume OpenIDs instead of (or in addition to) providing them? Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 03:17 PM, maiki wrote: Is this up for discussion, or are we at the point of planning deployment? The latter. I can elucidate a number of scenarios where that is beneficial, but the primary one from my perspective is that of authenticating for external tools (like bots and webservices) written by community developers. Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users. OpenID neatly fixes all that in one, simple to implement, open and well known manner. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 2013-02-22 3:34 PM, Ryan Lane rlan...@gmail.com wrote: I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects. My preference for this would be to have a centralized wiki for identity urls. The identity urls would be based on user pages. I'm proposing this for a few reasons: 1. It's easier to deal with identity urls in a centralized location, and it allows us to avoid including the OpenID extension on every wiki 2. We could very strictly limit our vulnerability surface on this wiki by only including what's necessary 3. At a later point we could decide to limit all authentication to this location, pointing login links from all projects/wikis here 4. At a later point we could decide to also use this as a global profile location I'd prefer if we avoid the bikeshedding of the domain name in this discussion, if we are all in agreement over the use of a centralized wiki. Thoughts? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l That sounds awesome. (Being a provider) When you say centralized wiki do you mean a preexisting wiki, or do you want to create a new wiki just for this? I would certainly prefer to use something that already exists. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 03:44 PM, Brian Wolff wrote: I would certainly prefer to use something that already exists. Meta would seem to be the natural, if ill-named, target. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
RE: https://www.mediawiki.org/wiki/Extension:OpenID (manual page) Just my few meta points: if you should find bugs so, please file them here https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=OpenID Open bugs are https://bugzilla.wikimedia.org/buglist.cgi?component=OpenIDresolution=--- These links are also at the bottom of the info box (manual page). Questions will certainly soon be answered by Ryan. Tom (Wikinaut and maintainer of E:OpenID) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 2013-02-22 4:43 PM, Marc A. . Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users. Actually theres been a centralized method of doing that for a while now (TUSC), so each tool is not reinventing the wheel, but open id sounds much less hacky. -bawolff P.s. I agree with Marc's comment about meta but didnt want to mention it out of concern for that being considered a bikeshed over which domain (but really meta seems the most logical place) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 03:50 PM, Brian Wolff wrote: Actually theres been a centralized method of doing that for a while now (TUSC), so each tool is not reinventing the wheel, but open id sounds much less hacky. Oh, cool. I did not know that. Of course, a /great/ transitional mechanism them presents itself: if TUSC is taught to speak OpenID, then all the tools using it benefit without having to be hacked at! -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Do you intend to cover both SUL and legacy accounts? I suspect that meta might not work due to the fact that there might be some accounts that were created on meta, but never merged. So either the URL would have to be different from the regular [[User:Xxx]] @ meta, like meta.wikimedia.org/user/sul/Xxxx (SUL account) or meta.wikimedia.org/user/enwiki/Xxxx (nonmerged enwiki-only account, or a new domain should be setup. On Fri, Feb 22, 2013 at 3:46 PM, Marc A. Pelletier m...@uberbox.org wrote: On 02/22/2013 03:44 PM, Brian Wolff wrote: I would certainly prefer to use something that already exists. Meta would seem to be the natural, if ill-named, target. -- Marc __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 22 February 2013 12:54, Yuri Astrakhan yuriastrak...@gmail.com wrote: Do you intend to cover both SUL and legacy accounts? I don't think it's worth anyone's time working out a way of supporting non-global accounts, given the on-going work to fix these as part of SUL finalisation which hopefully will get some finished soon. See https://www.mediawiki.org/wiki/Admin_tools_development#Roadmap for wider work in this area. (Please, let's not get side-tracked into discussing whether it should be meta or some other wiki or non-wiki domain.) 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] Caching Discussion: Dealing with old (deleted) wmf branches
On Feb 22, 2013, at 6:33 PM, Greg Grossmeier g...@wikimedia.org wrote: Hello all, Background and longer/more detailed discussion on this issue is in bug 44570: https://bugzilla.wikimedia.org/show_bug.cgi?id=44570 Summary: As w e delete old -wmfX branches there appears to be cached pages that reference old branch URLs, eg: https://bits.wikimedia.org/static-1.21wmf1/skins/common/images/poweredby_mediawiki_88x31.png (that 404s because 1.21wmf1 is long gone) If you want to see my bad ASCII art representation of our current caching layers, see this page: http://wikitech.wikimedia.org/view/Caching_overview So possible ways forward option 1: * reduce parsercache timeout to size of deployment window (~28 days) [0] * Tim may have knowledge why that shouldn't happen [1] Well, the obvious thing to do and imho what we should do, like, *right now* is extend the lifetime of the old branch to the timeout of the cache. Simply not deleting a directory is very, very easy. As far as I'm concerned we can agree right now not to delete any old branch from the servers until further notice (until we've figured out the max time age, and then implement the guard in multiversion/deleteMediawiki and then remove then when possible). option 2: * change away from version numbers in URLs [2] ** maybe use slots or something else ** skins? My bugzilla comment doesn't' suggest to change away from using these version numbers. It suggest to not use these urls directly in any code that makes it to the main html output. [0] https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c14 [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c12 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c15 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Self-signed cert on https://wikitech.wikimedia.org/
On Fri, Feb 22, 2013 at 12:35 PM, maiki ma...@interi.org wrote: Tested in Firefox and Chromium: wikitech.wikimedia.org uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_untrusted_issuer) FYI, nameless person who fixes that. ^_^ At least it's not expired anymore. :P -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 12:40 PM, Greg Grossmeier g...@wikimedia.orgwrote: quote name=maiki date=2013-02-22 time=12:17:25 -0800 Is this up for discussion, or are we at the point of planning deployment? It isn't apparent to me why any WMF site would be an OpenID provider. To phrase this differently: Do you more prefer that WMF sites consume OpenIDs instead of (or in addition to) providing them? This isn't really a matter of having one or the other. As Marc has mentioned, we need some non-hacky form of authentication for bots, tools, out-of-cluster applications, and non-mediawiki applications. OpenID as a consumer is a more difficult task for a number of reasons. I like to tackle problems one at a time and making a provider is an easy first step. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Caching Discussion: Dealing with old (deleted) wmf branches
quote name=Krinkle date=2013-02-22 time=22:29:00 +0100 Well, the obvious thing to do and imho what we should do, like, *right now* is extend the lifetime of the old branch to the timeout of the cache. Simply not deleting a directory is very, very easy. That is definitely a good stop-gap solution until we figure out a fix to the underlying issue. I haven't seen any objection to this suggestion either on the bug, on list, or in discussions in the office as a stop-gap type thing, so I'm comfortable with that for now. My bugzilla comment doesn't' suggest to change away from using these version numbers. It suggest to not use these urls directly in any code that makes it to the main html output. My apologies for misrepresenting it. That makes sense. I updated the wikitech page I started with a clarification (do let me know if I got it wrong still!) How can we prevent this issue from happening in the future without having old versions laying around? Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Ryan Lane rlan...@gmail.com I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects. I, too, want to clarify: you're proposing centralizing WMF identity to whatever extent it is not already centralized, and then using OpenID *within MWF*: so that all WMF sites and installed extensions can auth users against our own user database? Not authenticating users against external OID providers (which, as nearly as I can tell, largely amount to I am whom I say I am), or allowing external non-WMF sites to authenticate against our user database. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 1:03 PM, James Forrester jforres...@wikimedia.orgwrote: On 22 February 2013 12:54, Yuri Astrakhan yuriastrak...@gmail.com wrote: Do you intend to cover both SUL and legacy accounts? I don't think it's worth anyone's time working out a way of supporting non-global accounts, given the on-going work to fix these as part of SUL finalisation which hopefully will get some finished soon. See https://www.mediawiki.org/wiki/Admin_tools_development#Roadmap for wider work in this area. Totally agreed. I think it would be a waste of time to support non-global accounts. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
quote name=Ryan Lane date=2013-02-22 time=14:00:49 -0800 This isn't really a matter of having one or the other. As Marc has mentioned, we need some non-hacky form of authentication for bots, tools, out-of-cluster applications, and non-mediawiki applications. Right, figured not, just trying to clarify. OpenID as a consumer is a more difficult task for a number of reasons. I like to tackle problems one at a time and making a provider is an easy first step. Reasonable :) -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 2:03 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ryan Lane rlan...@gmail.com I believe the OpenID extension is matured to the point where it's usable on the Wikimedia projects, acting as an OpenID provider. The extension still needs review and such, but I think it's a good time to discuss how we'd like to implement this on the projects. I, too, want to clarify: you're proposing centralizing WMF identity to whatever extent it is not already centralized, and then using OpenID *within MWF*: so that all WMF sites and installed extensions can auth users against our own user database? Not authenticating users against external OID providers (which, as nearly as I can tell, largely amount to I am whom I say I am), or allowing external non-WMF sites to authenticate against our user database. Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 05:03 PM, Jay Ashworth wrote: or allowing external non-WMF sites to authenticate against our user database. Actually, that's the objective -- allow external tools to have their users be able to prove I am Wikimedia user Coren without having to hack around with edits-as-authentication-tokens or the enduser giving their credentials to some untrusted system. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Ryan wrote: Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider. There is currently no option, but an option (to restrict serving OpenIDs to certain consumer domains eg. only to our domain) could be implemented. Tom ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 2:30 PM, Thomas Gries m...@tgries.de wrote: Ryan wrote: Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider. There is currently no option, but an option (to restrict serving OpenIDs to certain consumer domains eg. only to our domain) could be implemented. I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikitech-l Digest, Vol 115, Issue 95
Thanks a lot Quim Gil :-) I want to fix bugs and looking for what can I do. I will check links and I am going to start fix bug. 22 Şub 2013 14:01 tarihinde wikitech-l-requ...@lists.wikimedia.org yazdı: ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless. Also, I think Wikipedia acting as an OpenID consumer would be bounds more useful than acting as a provider. That's not to say that having both wouldn't be a good idea, but the consumer side of it should definitely be a priority. Think of sites now like StackOverflow, where creating an account is as simple as pressing a few Accept buttons. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 22, 2013 at 5:37 PM, Ryan Lane rlan...@gmail.com wrote: On Fri, Feb 22, 2013 at 2:30 PM, Thomas Gries m...@tgries.de wrote: Ryan wrote: Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider. There is currently no option, but an option (to restrict serving OpenIDs to certain consumer domains eg. only to our domain) could be implemented. I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 2013-02-22 7:20 PM, Tyler Romeo tylerro...@gmail.com wrote: To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. Which coincides to several bots/tools and would generally be quite useful. Quite honestly having bots make edits directly on someones behalf using their account sounds scary. This would also be useful for test wikis people set up on labs. You could just authenticate via openid instead of creating a new account. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
This would also be useful for test wikis people set up on labs. You could just authenticate via openid instead of creating a new account. You can already test this here : http://openid-wiki2.instance-proxy.wmflabs.org/wiki ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 3:19 PM, Tyler Romeo tylerro...@gmail.com wrote: To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless. You're confusing use cases. What you're talking is the use case for OAuth. This thread isn't about OAuth. I believe we have plans to add OAuth next quarter, but if you wish to continue discussing it, please make a new thread. In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store. Also, I think Wikipedia acting as an OpenID consumer would be bounds more useful than acting as a provider. That's not to say that having both wouldn't be a good idea, but the consumer side of it should definitely be a priority. Think of sites now like StackOverflow, where creating an account is as simple as pressing a few Accept buttons. Sure, it would be great, but allowing authentication as a consumer is a much more difficult step, and we're not ready to take it right now. OpenID as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store. This is exactly what I'm saying. It doesn't do this. If a tool has a username/password store, i.e., it uses the username and password of each user, enabling OpenID wouldn't solve the authentication problem. Like I said, it only works in cases where the bot does all of its work under its own account. Sure, it would be great, but allowing authentication as a consumer is a much more difficult step, and we're not ready to take it right now. OpenID as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time. How exactly is it so difficult? You just set the configuration option for the extension. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 22, 2013 at 6:48 PM, Ryan Lane rlan...@gmail.com wrote: On Fri, Feb 22, 2013 at 3:19 PM, Tyler Romeo tylerro...@gmail.com wrote: To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless. You're confusing use cases. What you're talking is the use case for OAuth. This thread isn't about OAuth. I believe we have plans to add OAuth next quarter, but if you wish to continue discussing it, please make a new thread. In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store. Also, I think Wikipedia acting as an OpenID consumer would be bounds more useful than acting as a provider. That's not to say that having both wouldn't be a good idea, but the consumer side of it should definitely be a priority. Think of sites now like StackOverflow, where creating an account is as simple as pressing a few Accept buttons. Sure, it would be great, but allowing authentication as a consumer is a much more difficult step, and we're not ready to take it right now. OpenID as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 4:07 PM, Tyler Romeo tylerro...@gmail.com wrote: In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store. This is exactly what I'm saying. It doesn't do this. If a tool has a username/password store, i.e., it uses the username and password of each user, enabling OpenID wouldn't solve the authentication problem. Like I said, it only works in cases where the bot does all of its work under its own account. Let's consider bugzilla.wikimedia.org, for instance. It has its own credentials store. With OpenID as a provider on the projects, it could be possible to use your Wikimedia credentials rather than a username/password specific to bugzilla. In this situation bugzilla isn't acting on behalf of a user to interact with another application. An application acting on behalf of a user with another application is what OAuth does, not OpenID, and this thread isn't about that. Sure, it would be great, but allowing authentication as a consumer is a much more difficult step, and we're not ready to take it right now. OpenID as a provider solves some long-standing problems and is a step in the right direction, let's focus on one thing at a time. How exactly is it so difficult? You just set the configuration option for the extension. Feel free to bring this question up in another thread. Please search through the archives before doing so, though. I've answered this question numerous times over the past 2-3 years. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On Thu, Feb 21, 2013 at 2:01 PM, Tyler Romeo tylerro...@gmail.com wrote: - Where is QA? I mean, I know somewhere somebody is probably doing some sort of testing, but having worked as a QA engineer I haven't seen anything in MW that would resemble proper and traditional testing (excluding the unit testing). Where's the list of test cases that need to be performed for each release? How can one make new test cases and add them? etc. Maybe this already exists, but if it does it's definitely not documented well enough. Disclaimer: I am one of the QA people. We are testing all the time, but there are just 3-4 of us, as far as I know. We are looking for help. As far as I know, there will be Write your first Test Scenario in plain English event[1] on the week of March 11, if you would like to help. Feel free to add features/scenarios to the backlog[2] in the meantime. Let me know if you need help with that. (Test results for our browser automation project are available[3] to everybody, by the way). As an example, Siebrand provided a few features and scenarios[4] today and Chris and I have automated them[5][6]. (I have just noticed that the tests that we worked on today all failed because we make a mistake. It will be fixed probably on Monday.) Željko -- [1] http://www.mediawiki.org/wiki/QA/Weekly_goals [2] http://www.mediawiki.org/wiki/QA/Browser_testing/Test_backlog [3] https://wmf.ci.cloudbees.com/ [4] http://etherpad.wikimedia.org/i18n-qa [5] https://github.com/wikimedia/qa-browsertests/blob/master/features/accept_language.feature [6] https://github.com/wikimedia/qa-browsertests/blob/master/features/universal_language_selector.feature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On Fri, Feb 22, 2013 at 9:32 PM, Željko Filipin zfili...@wikimedia.org wrote: Feel free to add features/scenarios to the backlog[2] in the meantime. Let me know if you need help with that. (Test results for our browser automation project are available[3] to everybody, by the way). [snip] [3] https://wmf.ci.cloudbees.com/ So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Ryan Lane rlan...@gmail.com Any OpenID consumer, whether WMF or not, would be able to use us as an authentication provider. So, then, all OpenID guarantees is this provider says it's the same person it was last time? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 03:43 PM, Marc A. Pelletier wrote: On 02/22/2013 03:17 PM, maiki wrote: Is this up for discussion, or are we at the point of planning deployment? The latter. I can elucidate a number of scenarios where that is beneficial, but the primary one from my perspective is that of authenticating for external tools (like bots and webservices) written by community developers. Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users. OpenID allows you to tell a tool, I can prove I am User:JohnSmith on Wikimedia. That will work as a standard replacement for TUSC. Thus, tools like CommonsHelper (https://toolserver.org/~magnus/commonshelper.php) will be able to verify who you are. However, they will still have to do the actual edits/actions themselves. For instance, if you want CommonsHelper to do the actual upload, it's actually done by https://commons.wikimedia.org/wiki/User:File_Upload_Bot_%28Magnus_Manske%29 . A better solution would be OAuth, which is a more flexible way of letting apps act directly on a user's behalf in confined ways. For example, we could have OAuth scopes for: * Editing * Watchlist changes * Uploading and potentially many more. See https://www.mediawiki.org/wiki/OAuth#Scope Then, using the CommonsHelper example again, if I uploaded something through the OAuth version of that tool, it would show as uploaded by me. Another good part of OAuth is that individual users revoke an app at any time if it misbehaves. So OpenID is an interim step (and has secondary benefits), but I think OAuth is the way to go medium-term. People (including Chris Steipp) are already working on this, which is great. https://www.mediawiki.org/wiki/OAuth Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Ryan Lane rlan...@gmail.com I see no reason in doing so. If third parties want to allow Wikimedia as a provider, I don't see why we'd object. There is no potential liability there? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 06:33 PM, Brian Wolff wrote: Which coincides to several bots/tools and would generally be quite useful. Quite honestly having bots make edits directly on someones behalf using their account sounds scary. For autonomous bots, yes (they should keep using their own accounts). But for tools, it's common on other sites already, and makes sense here. Instead of the API requiring a user password and an elaborate token mechanism, it could just use OAuth. If an OAuth app misbehaves, a user can revoke it, or (in severe cases) it can be globally denied OAuth access. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 10:44 PM, Jay Ashworth wrote: There is no potential liability there? IANAL, but I can't think of a scenario where allowing a user to prove I am user X on Wikimedia projects can create liability; if the client is pleased with the (proven) assertion for their purposes, they can use it. If not, they won't. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
- Original Message - From: Marc A. Pelletier m...@uberbox.org On 02/22/2013 10:44 PM, Jay Ashworth wrote: There is no potential liability there? IANAL, but I can't think of a scenario where allowing a user to prove I am user X on Wikimedia projects can create liability; if the client is pleased with the (proven) assertion for their purposes, they can use it. If not, they won't. If those are the accepted semantics of the reply, then I retract the concern. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 10:43 PM, Jay Ashworth wrote: So, then, all OpenID guarantees is this provider says it's the same person it was last time? The exact semantics is, IIRC, that person has presented credential to us we accept as identifying them as our user $IDENTIFIER. Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Original Message - From: Marc A. Pelletier m...@uberbox.org On 02/22/2013 10:43 PM, Jay Ashworth wrote: So, then, all OpenID guarantees is this provider says it's the same person it was last time? The exact semantics is, IIRC, that person has presented credential to us we accept as identifying them as our user $IDENTIFIER. Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call. I'm translating that as yes. :-) I've always looked with rather a jaundiced eye at OpenID, as it was sold as you can run your own authenticator service, and that always struck me as I am who I say I am, which is, obviously, pretty useless, in the general case. (Early examples showed login boxes where you *provided the URL of a random OID provider*; clearly, if the site doesn't trust said provider, the transaction is useless.) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Gerrit e-mails from jenkins-bot
Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 2013-02-23 12:18 AM, Jay Ashworth j...@baylink.com wrote: Original Message - From: Marc A. Pelletier m...@uberbox.org On 02/22/2013 10:43 PM, Jay Ashworth wrote: So, then, all OpenID guarantees is this provider says it's the same person it was last time? The exact semantics is, IIRC, that person has presented credential to us we accept as identifying them as our user $IDENTIFIER. Whether the client trusts that $IDENTIFIER is reasonably stable for their purposes, or that they trust our word, is their call. I'm translating that as yes. :-) I've always looked with rather a jaundiced eye at OpenID, as it was sold as you can run your own authenticator service, and that always struck me as I am who I say I am, which is, obviously, pretty useless, in the general case. (Early examples showed login boxes where you *provided the URL of a random OID provider*; clearly, if the site doesn't trust said provider, the transaction is useless.) Cheers, -- jra -- While that depends on your use case. In many situations it is the user's (and only the user's) problem if the oid provider is untrustworthy. It then becomes the users responsibility to pick a good oid provider. ( giving users security responsibilities - because that has never gone wrong ;). That said, in many ways no different from normal passwords: Users arent supposed to share passwords - users aren't supposed to pick oid providers they don't trust. What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 02/22/2013 11:32 PM, Brian Wolff wrote: What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On 2013-02-23 12:37 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/22/2013 11:32 PM, Brian Wolff wrote: What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Presumably you would have to do that before the downtime though as you wouldn't be able to login once downtime starts. So one could easily be caught off guard. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit e-mails from jenkins-bot
On 22 February 2013 20:30, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. These e-mails mean something (well, some of them do, namely that you - you the submitter, you the merger/potential merger, or you the bystander that gets these e-mails anyway - screwed up and it's -1'ed for some reason). However, killing off the ones which add no data (the expected outcome is that everything's fine) would be nice. Clearly we currently suppress e-mails for the internationalisation bot (even though some of us would actually like to get those), but yes being able to kill the valueless ones would be good; being able to switch them back on opt-in for jenkins, and for i18n-bot, might make sense. 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] Bringing OpenID as a provider to Wikimedia projects
So I definitely see the use case for OpenID as a provider (and as long as everybody is aware that OpenID is not OAuth, I'm fine with that), but I'm not a bot/tool developers. I am, however, a frequent user of the Internet, and I find it extraordinarily surprising that Wikipedia is one of the few sites still out there that doesn't have some sort of OpenID login. My main question is that if we're really taking the time to deploy Extension:OpenID on WMF wikis, why not put in the extra ten seconds to also allow consumers. People keep going on about how the account creation process is ugly and needs to be re-designed, and yet with OpenID it takes three clicks to register an account, and especially with the recent version push Thomas did, it's better than ever. Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime. E:OpenID does this as well, not to mention you can always set a password and login traditionally. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 22, 2013 at 11:40 PM, Brian Wolff bawo...@gmail.com wrote: On 2013-02-23 12:37 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/22/2013 11:32 PM, Brian Wolff wrote: What ive always wondered is what happens if your oid provider goes under/otherwise dissapears. I imagine that means you lose your user account all across the internet, which is a scary thought Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Presumably you would have to do that before the downtime though as you wouldn't be able to login once downtime starts. So one could easily be caught off guard. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit e-mails from jenkins-bot
On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot). I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit e-mails from jenkins-bot
On 2013-02-23 1:15 AM, Chad innocentkil...@gmail.com wrote: On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot). I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering. -Chad Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit e-mails from jenkins-bot
On Sat, Feb 23, 2013 at 12:19 AM, Brian Wolff bawo...@gmail.com wrote: On 2013-02-23 1:15 AM, Chad innocentkil...@gmail.com wrote: On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot). I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering. -Chad Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that? But if we omit the e-mails from being sent, how will the people who want the e-mails get them? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit e-mails from jenkins-bot
On 2013-02-23 1:24 AM, Chad innocentkil...@gmail.com wrote: On Sat, Feb 23, 2013 at 12:19 AM, Brian Wolff bawo...@gmail.com wrote: On 2013-02-23 1:15 AM, Chad innocentkil...@gmail.com wrote: On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot). I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering. -Chad Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that? But if we omit the e-mails from being sent, how will the people who want the e-mails get them? -Chad I was assuming that no one wanted emails for the all unit tests passed situation. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit e-mails from jenkins-bot
On Sat, Feb 23, 2013 at 12:27 AM, Brian Wolff bawo...@gmail.com wrote: On 2013-02-23 1:24 AM, Chad innocentkil...@gmail.com wrote: On Sat, Feb 23, 2013 at 12:19 AM, Brian Wolff bawo...@gmail.com wrote: On 2013-02-23 1:15 AM, Chad innocentkil...@gmail.com wrote: On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z...@mzmcbride.com wrote: Matthew Flaschen wrote: On 02/22/2013 09:38 PM, Chad wrote: So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things. I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit. Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like. I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated. Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot). I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering. -Chad Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that? But if we omit the e-mails from being sent, how will the people who want the e-mails get them? -Chad I was assuming that no one wanted emails for the all unit tests passed situation. Well, maybe I'm alone :\ -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
see also https://bugzilla.wikimedia.org/show_bug.cgi?id=9604 (2007) Support OpenID extension on all wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Am 23.02.2013 05:40, schrieb Brian Wolff: Some sites, like Stack Overflow, allow you to add alternate OpenIDs, which helps for temporary or permanent downtime. Presumably you would have to do that before the downtime though as you wouldn't be able to login once downtime starts. So one could easily be caught off guard. -bawolff E:OpenID is usually configured for standard (password) Login or OpenID Login, so with E:OpenID-enabled MediaWIkis (as Consumer) you are on the safe side regarding this aspect. You can associate one or many OpenIDs to your account. You can manage your OpenIDs (add further, delete unwanted) in a new preferences tab OpenID. T. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
Am 23.02.2013 00:48, schrieb Ryan Lane: On Fri, Feb 22, 2013 at 3:19 PM, Tyler Romeo tylerro...@gmail.com wrote: To be absolutely clear, this does *not* solve the problem of bots/tools authenticating on behalf of a user. All it does is solve the problem of where a bot/tool authenticates under its own user account and, out of pure courtesy for the community, asks users to prove their identity before allowing them to use the bot/tool. For bots/tools that actually perform edits as the user, OpenID would be useless. You're confusing use cases. What you're talking is the use case for OAuth. This thread isn't about OAuth. I believe we have plans to add OAuth next quarter, but if you wish to continue discussing it, please make a new thread. In cases where a tool is keeping an authentication database, and is not acting on behalf of a user, then OpenID would let the tool eliminate its username/password store. Here is a nice figure taken from https://developers.google.com/accounts/docs/OpenID In case you cannot see the figure in the mail, goto section Interaction_sequence OpenID login process ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
