MediaWiki-Core October 2014

mediawiki-core@lists.wikimedia.org

11 participants
6 discussions

Security related things to extract as libraries?
by Bryan Davis 01 Nov '14

01 Nov '14

I was poking around in UploadBase today because Quim asked how we checked SVGs to make sure they are not full of nasty javascript stuff and realised that we have a non-trivial amount of code in there for that purpose. That got me wondering if that code and other scanning and filtering things would be a good candidate for a library to extract share with the wider world. Thoughts? Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

3 2

Re: [MediaWiki-Core] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 23 Oct '14

23 Oct '14

Minutes and slides from the recent quarterly review meeting of the Foundation's MediaWiki Core team can now be found at https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revi… . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

1 0

Fwd: Self-reviews in core between 1.22 and 1.23
by Greg Grossmeier 15 Oct '14

15 Oct '14

Hey guys, See this note from Katie. Summary: 1) PCI compliance says that the code they deploy to the payments cluster must have peer-review. 2) There are 35 commits to core that are self-merged with no review (see Elliot's script). Retroactively +1ing the changes is probably sufficient (after you've reviewed the change, of course :) ). Deadline appears to be "before November". Help? Greg PS: Katie is cc'd, but I don't think she is on ourlist. ---------- Forwarded message ---------- From: Katie Horn <khorn(a)wikimedia.org> Date: Tue, Oct 14, 2014 at 3:59 PM Subject: Self-reviews in core between 1.22 and 1.23 To: Greg Grossmeier <greg(a)wikimedia.org> Hey Greg, Thanks for looking in to this. Elliott came up with the following awk script and its subsequent output, both attached. To summarize: PCI rules say that we can not deploy code to payments systems if there were any unreviewed (self-merged) patches, and we found about 35 in the upgrade of mediawiki core that fundraising would like to do before November. It should be sufficient to have somebody other than the original committer retroactively +1 the patch in gerrit. Just so I can prove everything had extra eyes on it before we deploy the code to payments. Please let me know if something went wrong with the attachments, and I will gladly resend. Thanks! -Katie ---------- Forwarded message ---------- From: Elliott Eggleston <eeggleston(a)wikimedia.org> Date: Tue, Oct 14, 2014 at 3:48 PM Subject: Fwd: Fwd: For your inner PCI lawyer To: Katie Horn <khorn(a)wikimedia.org> Do this log command and the attached awk script look correct? git log --no-merges --show-notes=review --name-status fundraising/REL1_22..REL1_23 -- *php *php5 skins resources includes > allLog ./findSelfMerge.awk < allLog > unreviewed.txt -- Greg Grossmeier Release Team Manager

3 2

Fwd: [Bug 71862] "There was an unexpected error logging in" when creating accounts on Beta
by Greg Grossmeier 12 Oct '14

12 Oct '14

A login/account creation issue we found on beta cluster is now on production. Help very much appreciated before it goes out further (or we have to revert/hold the train). Greg -- Sent from my phone, please excuse brevity. ---------- Forwarded message ---------- From: <bugzilla-daemon(a)wikimedia.org> Date: Oct 11, 2014 4:16 PM Subject: [Bug 71862] "There was an unexpected error logging in" when creating accounts on Beta To: <greg(a)wikimedia.org> Cc: Sam Reed (reedy) <sam(a)reedyboy.net> changed bug 71862 <https://bugzilla.wikimedia.org/show_bug.cgi?id=71862> What Removed Added Priority Normal Highest *Comment # 12 <https://bugzilla.wikimedia.org/show_bug.cgi?id=71862#c12> on bug 71862 <https://bugzilla.wikimedia.org/show_bug.cgi?id=71862> from Sam Reed (reedy) <sam(a)reedyboy.net> * Seems to be affecting production now... ------------------------------ You are receiving this mail because: - You are on the CC list for the bug.

2 2

Team mission
by Bryan Davis 07 Oct '14

07 Oct '14

I'm trying to compare the feeling of the group (that we know exactly why we are here and how this aligns with the WMF mission) and my personal feeling (that we do whatever is asked and often the asks are questionable). I'm willing to admit that some of the difference in viewpoint is based on the particular work that I have done over the last year. I have been on loan to Multimedia, developed Wikimania Scholarships, on loan to Release Engineering and developed IEG grant review. In between and overlapping I worked briefly on the "DevOps sprint", setup logstash, rewrote scap and dabbled in HHVM related research. This level of bouncing around and number of solo projects has not given me a great feeling that I'm on a well scoped team. It actually makes me feel like I'm just a gun for hire (or worse monkey at a keyboard) to be called to service whenever and wherever RobLa and Erik feel an extra hand is needed. I'm not looking for pity or a "you're doing good job Bryan" out of this rant, I'm just trying to make my point of view clear. I've actually generally enjoyed the work that I've done here and have certainly had plenty of things to keep me busy and learning. I am however interested in acquiring a better model of what it is that I should be trying to do when I have the opportunity to choose work from the never ending list of things that could be done. I feel that this is important not just for me personally but for the team as a group when doing things like grooming our collective project backlog and defending our choices to management. I went to the wiki page for our group [0] and found this list of "responsibilities" for the MediaWiki Core team: * Manage the MediaWiki release cycle * Ensure that MediaWiki core is meeting the evolving needs of the website * Make quality MediaWiki releases available for others outside of the Wikimedia Foundation * Develop and document a clear set of APIs so that external developers can create applications that easily interface with MediaWiki This seems out of date to me. I think that the newly formed Release Engineering team is responsible for the first and third bullet points. That leaves "meeting the evolving needs of the website" and "develop and document a clear set of APIs" still on our plate. Neither of these seems like something that can be used to exclude much work from consideration. This can be seen as a good thing when the team is presenting their ideas outwardly, but it seems like a double edged sword for incoming work requests. It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations. I think it would be a worthwhile exercise to spend some time next week talking about what it is that we do here and what reasonable boundaries and expectations we would like to set with the Foundation and the community. [0]: https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering#MediaWiki_Core Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

6 9

Library infrastructure project ideas
by Bryan Davis 01 Oct '14

01 Oct '14

I've started an etherpad [0] with some ideas about what we could try to do for the Q2 Library infrastructure project. Since this morphs a bit every time two or more of us talk about it, I'd like to get some collective notes/input before we walk into the quarterly review to pitch the idea and let the group there tell us what we should be doing. I know that I want to finish the logging work. I think this can be used as a good example of how to consume external libraries in MediaWiki core as well as helping solve a real deficiency in our existing code base. My RFC on the topic is a good start but the processes and procedures outlined there need to be published in a more visible place on wiki and battle tested for deficiencies. I think I'd also like to see the Profiler work done as I've heard that many components in MediaWiki are basically only tied to logging and profiling. I'm totally willing to be persuaded that there is a better candidate for extracting into a library however. One question I'd like to ask is "what functionality from MediaWiki do you miss when you write a standalone PHP app?" Database? Caching? I18n bits and pieces? Is one of these more compelling for extracting and publishing than the profiler? I'd also like to hear ideas about how we should be documenting the extracted libraries. Should we have a different workflow for generating docs from code? Is publishing docs as wiki pages a good, bad or meh idea? If we don't document on wiki how can we encourage document contributions from casual users? If we do document on wiki how can we ensure that changes in the API are propagated to the documentation soon after merge? How important is localization for code documentation? In case you are wondering "who put Bryan in charge here?", the answer is RobLa. :) Following in the model of the HHVM project where Ori has been acting as project manager / product owner, RobLa has tapped me to take the lead on organizing the library infrastructure project if it gets green lighted. I'll need a lot of help since I still don't know as much about MediaWiki itself as our average 13 year old contributor, but I hope I can be of service with my experience in project and product management. [0]: https://etherpad.wikimedia.org/p/MWCoreLibraryInfrastructure Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

MediaWiki-Core October 2014