[Wikitech-l] Gerrit and CI shortly unavailable
Hello, We are proceeding with an unscheduled operation on servers that host Gerrit and the continuous integration systems. Both are going to be shortly unavailable over the course of next hour as we restart them. Gerrit would be unavailable for a mew minutes. CI for an half an hour or so. I will reenqueue changes in CI once the maintenance is completed. Sorry for the short notice. -- Antoine Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Setting up a new Tomcat servlet in production?
On Thu, Oct 20, 2016 at 10:20 AM, 魔法設計師 wrote: > 2016-10-19 0:45 GMT+08:00 Alexandros Kosiaris : >> >> Hello, >> >> With the preamble of my opinion not being an authoritative point of >> view at all, I should point out that Java/JVM based services are not >> especially loved in WMF. Ops does not feel it has the capability of >> supporting them. There are a few around like Gerrit, Cassandra, >> ElasticSearch, Kafka but none of these is actually maintained by ops. >> All of these have owners/maintainers outside of ops (entire teams in >> some cases), with varying degrees of success. The question of whether >> it should be Tomcat or Jetty, is a valid one, but serves to alleviate >> only part of the problem (it's not like Ops hate tomcat but like >> Jetty). So, there are probably a few social/administrative issues that >> it might make sense to address first before handling the technical >> part. > > I think what you means is : if the service is online,for administration , > a maintainer or a team is needed just like Gerrit,Cassandra, and > ElasticSearch did. Not maintained by the OPs. The team need to be set > first. Am I right? Yes, that's the very least IMHO. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit and CI shortly unavailable
On 24/10/16 10:32, Antoine Musso wrote: Hello, We are proceeding with an unscheduled operation on servers that host Gerrit and the continuous integration systems. Both are going to be shortly unavailable over the course of next hour as we restart them. Gerrit would be unavailable for a mew minutes. CI for an half an hour or so. I will reenqueue changes in CI once the maintenance is completed. Sorry for the short notice. Hello, Reboots are now completed and both Gerrit and CI are back in action. -- Antoine Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying the Linter extension to Wikimedia wikis
Legoktm wrote: >Arlo and myself have been working on a new MediaWiki extension to expose >Parsoid's "lint errors" to users. > >[...] > >The main advantage of this over tracking categories is that we know the >location in the wikitext so it should be easier to identify the error >and fix it, as well as knowing whether the issue was caused via a >template or not. Nice. (I haven't read/skimmed any of the code yet.) How will the errors be queried? Will be there an api.php module to query on a per-error or per-page basis? Does the extension distinguish between errors and warnings? Are there gradations of errors? For example, deprecated syntax v. invalid syntax? I wonder if the name "Linter" is overly generic. This extension will only activate on wikitext, correct? It won't lint other content models/types such as JavaScript and CSS? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploying the Linter extension to Wikimedia wikis
On 10/24/2016 08:42 AM, MZMcBride wrote: Does the extension distinguish between errors and warnings? Are there gradations of errors? For example, deprecated syntax v. invalid syntax? Technically, there are no errors with wikitext ... but yes, Parsoid knows what some of these "errors" are and they are tagged with different category names which can be tweaked as necessary. And, other deprecations can be targeted and marked up. I wonder if the name "Linter" is overly generic. This extension will only activate on wikitext, correct? It won't lint other content models/types such as JavaScript and CSS? Maybe WikiLint? That could play on the notion that, for most users, wiki = wikitext. -S. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Invitation for review: Technical Collaboration Guideline
Greetings, Wikimedians, please review something we are working on for the Wikimedia Foundation, the Technical Collaboration Guideline [0]. The Technical Collaboration Guideline (TCG) is a set of best practice recommendations, for planning and communicating product and project information to Wikimedia communities, in order to work better, together. The TCG allows Wikimedia Foundation (WMF) Product teams and Wikimedia communities to work together in a systematic way in the product development and deployment cycle. It is hoped that the TCG is useful enough to be utilized in planning and communications regarding any project, from anyone. The TCG is intended to be flexible as plans and products change in development; it is a guide whose contents will help build collaborative relationships. The initial draft of the TCG was written after discussions in small groups with members of the Community Liaisons and Product Management teams, to identify successes and failures in communication, and what we can do to encourage collaboration with the communities. Over the next month, I am seeking review and feedback from Wikimedia community members. All feedback that is left will be read; if there is a case for immediate action, it will be made. All feedback will be taken into consideration when editing the next draft of the TCG. Please keep in mind that the TCG is intended to be lightweight information and instruction and will not be completely comprehensive. The TCG and the conversations about it are in English, but comments from all languages are welcome. Over the next few days, this invitation for review will be distributed across the wikis. Also, within the coming weeks, I'll be announcing a review on behalf of the WMF's Design team. They have been working diligently over the past few months to identify and define the purpose of design within the WMF, and they are looking forward to sharing this statement of purpose with the broader Wikimedia movement for comment. If you're interested, please be on the lookout for this review announcement. I look forward to reading your comments on the wiki [1]. 0. https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline 1. https://www.mediawiki.org/wiki/Talk:Technical_Collaboration_Guideline -- Keegan Peterzell Technical Collaboration Specialist Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] The Revision Scoring weekly update
Hey, This is the 26th and 27th weekly update from revision scoring team that we have sent to this mailing list. We forgot to send the update for last week! Last week, we were featured in Research's quarterly review. In the last 3 months, we achieved our goals to expand the ORES extension to 6 wikis (we made it to 8!) and to release datasets of article quality predictions. The minutes from the quarterly review are not yet online, but once they are, you'll be able to see them at [1]. Maintenance and robustness: - We discussed and decided on a set of strategies for handling goodfaith/naive DOS attacks on ORES[2] - We fixed an i18n issue in Wiki Labels[3] - We updated the article quality models (wikiclass/wp10) to use revscoring 1.3.0[4] - We investigated and solved a memory leak in our pre-caching utility[5] - We configured celery to send its logs to a place where we can read them for easier debugging[6] - We deployed a set of schema changes to constrain the ORES Review Tools database appropriately[7] - Also worth noting is that the services cluster (SCB) has been expanded[8]. ORES has now doubled in capacity Datasets - We discussed how to make the historical article quality dataset available via quarry[8]. Regretfully, it seems that we'll not be able to do that for at least a couple of months. New development - We've implemented embedding of machine-readable scores in a JS variable on-wiki[9]. This will make it easier for tool developers to experiment with new ways of displaying Special:RecentChanges more easily. It's also a necessary precondition for adding color-based signaling of ORES' confidence about an edit. 1. https://meta.wikimedia.org/wiki/Wikimedia_Foundation_metrics_and_activities_meetings/Quarterly_reviews/Research,_Design_Research,_Analytics,_and_Performance,_October_2016 2. https://phabricator.wikimedia.org/T148347 -- [Discuss] DOS attacks on ORES. What to do? 3. https://phabricator.wikimedia.org/T139587 -- Revision not found error unformatted and not localized 4. https://phabricator.wikimedia.org/T147201 -- Update wikiclass for revscoring 1.3.0 5. https://phabricator.wikimedia.org/T146500 -- Investigate memory leak in precached 6. https://phabricator.wikimedia.org/T147898 -- Send celery logs to /srv/log/ores instead of /var/lib/daemon.log 7. https://phabricator.wikimedia.org/T147734 -- Review and deploy 309825 8. https://phabricator.wikimedia.org/T147903 -- Expand SCB cluster 9. https://phabricator.wikimedia.org/T146718 -- [Discuss] Hosting the monthly article quality dataset on labsDB 10. https://phabricator.wikimedia.org/T143611 -- Embed machine readable ores scores as data on pages where ORES scores things Sincerely, Aaron from the Revision Scoring team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 1.28 branching release dates and such :)
Hi! S, it's that wonderful time of year where we start prepping for a new general release of MediaWiki! This one will be 1.28.0, and it'll be based on all of the 1.28 wmf branches we've been doing over the past 6 months. Step 1 is cutting the branch, which I plan to do tomorrow from the same branch point which we cut the 1.28.0-wmf.23. This is slightly different, in that we won't be cutting from master a few days after the WMF branch, and takes some of the pressure off of creating 1.29.0-wmf.1 the following week. So here's the timeline: Tomorrow (Oct 25) - Cut REL1_28 from wmf.23, master goes to 1.29-alpha Tues (Nov 1) - First deployment of 1.29 to WMF [wmf.1, obviously] Wednesday (Nov 2) - Do rc.0 [giving us a few days for any backports that came up in wmf.23 rollout] Following two Wednesdays (Nov 9, 16) - Do rc.1 and rc.2 Wednesday (Nov 23) - Final release of MW I'll be updating MW.org shortly. Tyler Cipriani's assisting me with this release, so expect to see some RCs with his name (and signatures) on them :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
