Hi list,
is there a procedure/best practice to automatically transfer old SVN
style extensions to GIT?
Is this something the maintainer of an extension needs to do?
An example would be: https://www.mediawiki.org/wiki/Extension:DateDiff
/planetenxin
Hello,
Zeljko and I will upgrade Jenkins on Wednesday July 8th at 8:00am UTC
(10:00am CET).
There will be roughly half an hour downtime. Zuul will keep queueing the
changes and trigger the jobs whenever Jenkins comes back up.
In case of crazy side effect, we will revert back to the current version.
Expected downtime is half an hour but I scheduled a two hours
maintenance window.
https://phabricator.wikimedia.org/T101884https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=169423&ol…
--
Antoine "hashar" Musso
Hello!
In this thread
<https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Userpage_d…>,
there was a discussion about indexing of user space by search engines. In a
nutshell, user space pages are not subject to content policies so that
users can write drafts freely, and having those pages indexed by search
engines like Google is viewed as problematic since those pages can seem
fairly official.
I seem to recall that it was not the default in the past that user pages
were indexed by search engines. I'm trying to figure out if there's some
other cause for this that's happened recently, because I'd prefer to avoid
piling hacks on and not address the root issue.
Does anyone know of anything that's changed recently that might've changed
the way that search engines index user space?
Thanks,
Dan
--
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
Some of you may have noticed a bot [1] providing reviews for the
Mobilefrontend and Gather extensions.
This is a grass routes experiment [2] to see if we can reduce
regressions by running browser tests against every single commit. It's
very crude, and we're going to have to maintain it but we see this as
a crude stop gap solution until we get gerrit-bot taking care of this
for us.
Obviously we want to do this for all extensions but we wanted to get
something good enough that is not scaleable to start exploring this.
So far it has caught various bugs for us and our browser test builds
are starting to finally becoming consistently green, a few beta labs
flakes aside [3].
Running tests on beta labs is still useful but now we can use it to
identify tests caused by other extensions. We were finding too often
our tests were failing due to us neglecting them.
In case others are interested in how this is working and want to set
one up themselves I've documented this here:
https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot
Please let me now if you have any questions and feel free to edit and
improve this page. If you want to jump into the code that's doing this
and know Python check out:
https://github.com/jdlrobson/Barry-the-Browser-Test-Bot
(Patches welcomed and apologies in advance for the code)
[1] https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c…
[2] https://phabricator.wikimedia.org/T100293
[3] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
Hello all,
First, some history and context:
The #roadmap project[0] in our Phabricator instance was set up by Erik M
as a trial way of tracking upcoming releases, deployments, and generally
"new things of note", as these previously weren't tracked in one place.
It has a workboard[1] that is is broken up into:
* one column for each week for the current month
* one column for each remaining month in the current quarter
* then "not soon"
The scope of this project covered both "things that might break the site
or are otherwise risky" and also "things people might expect to be
notified about". At the time things got released quite often without a
standard way for people to find that they were coming.
I helped Erik with maintaining this project because it was also useful
for our weekly "roadmap and deployments update" meeting where most WMF
engineering managers got together for about 15-30 minutes to go over:
* What, of note, is going out next week?
* What, of note, is going out in the near term (i.e.: next few weeks)?
* Anything else we should know about?
Outcomes of this meeting were:
* An updated outline of upcoming deployments on the Deployment
Calendar[2]
** This helped inform the work of the WMF RelEng and Ops teams,
especially
* A time/space for people (especially Erik or others with intimate
"community knowledge/intuition") to object to something going out at
all, or at the proposed time
Since this project was set up, Guillaume started the #user-notice and
#developer-notice projects [4][5], which cover the "things to tell
people about" a lot better, are much more general covering incidents and
planned outages as well as code deployments, and are communicated out
via volunteer translators to dozens of community notice boards every
week.
== Current world / Assessment ==
We are still using the #roadmap project for a lot of things that don't
risk deployment/stability disruption, and also updating the Deployments
Calendar on wikitech. It is my opinion that there is not enough gain
from maintaining both work products to justify the effort, especially as
#user-notice and #developer-notice have become so valuable.
== Proposal ==
I propose that we discontinue the use of #roadmap.
Potential gaps created by the deprecating of #roadmap and my proposed
solutions:
* Lack of a project that tracks big upcoming software/product releases
** The #release[3] project was created for this
* Lack of a time-scale perspective of upcoming releases/deployments
** I believe that the Deployments Calendar[2], while imperfect (wiki
templates), fulfills this
* Users aren't informed of upcoming changes
** the #user-notice[4] project in Phabricator should be used for that
== Expectations ==
To successfully do this (deprecate #roadmap) I expect all WMF
Engineering teams (as the group of developers I have more influence over
versus the Wikimedia engineering community) to pro-actively communicate
out their plans, in public, with the appropriate use of the Deployments
Calendar and the #user-notice Phabricator project. This means engaging
with the Community Engagement/Liaison team when appropriate.
In no small way this is me, as Release Manager, showing trust in the
work of the WMF Engineering teams (which includes the product managers).
Do good things with it :-)
Let me know if you have any concerns,
Greg
[0] https://phabricator.wikimedia.org/project/profile/1109/
[1] https://phabricator.wikimedia.org/project/board/1109/
[2] https://wikitech.wikimedia.org/wiki/Deployments
[3] https://phabricator.wikimedia.org/project/profile/1333/
[4] https://phabricator.wikimedia.org/tag/user-notice/
[5] https://phabricator.wikimedia.org/tag/developer-notice/
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
cc wikitech - I think this is important for all of us to think about -
not just those working on mobile, since mobile still loads a lot of
what desktop does...
On Mon, Jul 6, 2015 at 8:40 AM, Joaquin Oltra Hernandez
<jhernandez(a)wikimedia.org> wrote:
> Hey,
>
> I saw the other day a performance audit that Paul Irish did for the mobile
> site of reddit.
>
> It is a great audit and a great example of how to do a performance review of
> a site, I encourage all to carefully read it as we are going to have to do
> something similar in the following sprints in order to enable us to do more
> concrete performance work on the mobile website.
>
> https://github.com/reddit/reddit-mobile/issues/247
>
> Awesome stuff.
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
Call for participation in OpenSym 2015!
Aug 19-20, 2015, San Francisco, http://opensym.org
----
FOUR FANTASTIC KEYNOTES
Richard Gabriel (IBM) on Using Machines to Manage Public Sentiment on Social Media
Peter Norvig (GOOGLE) on Applying Machine Learning to Programs
Robert Glushko (UC BERKELEY) on Collaborative Authoring, Evolution, and
Personalization
Anthony Wassermann (CMU SV) on Barriers and Pathways to Successful Collaboration
More at
http://www.opensym.org/category/conference-contributions/keynotes-invited-t…
----
GREAT RESEARCH PROGRAM
All core open collaboration tracks, including
- free/libre/open source
- open data
- Wikipedia
- wikis and open collaboration, and
- open innovation
More at
http://www.opensym.org/2015/06/25/preliminary-opensym-2015-program-announce…
----
INCLUDING OPEN SPACE
The facilities provide room and space for your own working groups.
----
AT A WONDERFUL LOCATION
OpenSym 2015 takes place from Aug 19-20 at the Golden Gate Club of San
Francisco, smack in the middle of the Presidio, with a wonderful view of the
Golden Gate Bridge.
More at http://www.opensym.org/os2015/location/
----
REGISTRATION
Is simple, subsidized, and all-encompassing.
Find it here: http://www.opensym.org/os2015/registration/
Prices will go up after July 12th, so be sure to register early!
----
We would like to thank our sponsors Wikimedia Foundation, Google, TJEF, and
the ACM.
The 2015 Seattle GNU/Linux conference (SeaGL) call for proposals is now
open. I've submitted a proposal for a 50-minute workshop regarding how to
edit Wikipedia, and may submit more proposals in collaboration with my
colleagues in Cascadia Wikimedians. I'm sure that SeaGL would be happy to
consider technical presentations about MediaWiki, Wikimedia analytics,
Wikimedia Labs, our upstream tools, etc. if you're interested. Please
consider submitting a proposal and coming to Seattle for the conference.
http://seagl.org/
Regards,
Pine
