I've already posted to mediawiki-l to try and get input from end users
on these proposed changes [1], but I'd like to see if we can't change
the RELEASE-NOTES format for the time that we're working on 1.23.
The main thing I've done is a bit of reordering and collection:
* New features
* Breaking changes (collected in a single section)
* Configuration changes
* Bug fixes
* API changes
* Language updates
* Misc changes
This is an effort to put the things users to know most about in a new
release at the top of the file.
This could even be done using git comments as others have suggested.
Does this seem like a reasonable approach going forward?
Thanks for any comments,
Mark.
[1] http://article.gmane.org/gmane.org.wikimedia.mediawiki/42443
Hi, I'd like to announce a new RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction
It deals with how we want MediaWiki text extracts to live on now that
this functionality can be moved out of MobileFrontend.
Your feedback would be higly appreaciated!
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hello everyone,
I'm an applicant of FOSS-OPW Round 7 and I have interest at MediaWiki
Homepage Redesign project.
Project Synopsis:
The mediawiki.org Main page needs a redesign to reflect better our project
an the activities done by our community. There have been some proposals to
improve it, but not much progress has been done. This project requires to
analyze the current problems, propose a solution and implement it, being
all these steps done with the participation of the community.
Possible mentor: Quim Gil
The MediaWiki Homepage Redesign project aims to redesign the homepage
MediaWiki to express for community the full potential of MediaWiki. The
homepage is the first contact that community has with the tool, is in this
moment that we need awakening the interest to know and use the it.
You can see more about me and my intentions here [1].
Thanks for attention.
[1] https://www.mediawiki.org/wiki/User:Monteirobrena
Brena Monteiro
+55 31 9265-2020
@monteirobrena <http://twitter.com/monteirobrena>
Reflexões Brenianas <http://monteirobrena.wordpress.com>
There was a report of external issues reaching en.wikipedia.org - nginx
timeouts - about 1 hour ago, also reported resolved.
Forwarding in from outages-l as I haven't seen any internal discussion...
-george
---------- Forwarded message ----------
From: Marco Davids (SIDN) <marco.davids(a)sidn.nl>
Date: Fri, Nov 8, 2013 at 10:29 AM
Subject: [outages] Wikipedia down?
To: "outages(a)outages.org" <outages(a)outages.org>
I get an error-page on:
http://en.wikipedia.org/wiki/Sun_Secure_Global_Desktophttps://twitter.com/marcodavids/status/398878863071006720
--
Marco
_______________________________________________
Outages mailing list
Outages(a)outages.org
https://puck.nether.net/mailman/listinfo/outages
--
-george william herbert
george.herbert(a)gmail.com
Hi,
https://www.mediawiki.org/wiki/Architecture_Summit_2014#Participants has
been updated in order to reflect the current list of participants
confirmed.
We are in touch with a few contributors from areas currently
underrepresented, and it is possible that some people are still added to
the list.
Volunteer contributors requiring sponsorship will be contacted via
email. The Wikimedia Foundation will cover their flights and
accommodation. Please email me if you don't hear from us this week.
Wikimedia Foundation employees not based in San Francisco must contact
their managers for travel arrangements.
The first MediaWiki Architecture Summit 2014 is looking great at least
in terms of participation. Next: content. Now it's time to focus in the
discussions prior to the event, and the schedule.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi folks,
after speaking to a few folks, I'd like to check in on the WMF deployment
train schedule overall, and see if there are ways to optimize it.
(Note: In the below I refer to "test wikis" vs. "production wikis",
generously including mediawiki.org as a test wiki. I realize that our "test
wikis", with the exception of Labs wikis, run on the production cluster.)
== Current practice ==
* On Thursdays we increase the release counter, and deploy the latest
release to test wikis and the previous one to Wikipedias.
* On Mondays we deploy the latest release to non-Wikipedias.
== Problems with this approach ==
* We only have bits of Thursday and all of Friday to resolve issues that
are surfaced in the test wikis prior to the Monday rollout to the first
production wikis.
* Having two stages of release also increases the cognitive load on
developers in understanding when their code hits production wikis, which
arguably increases the risk of negative impact of a deploy going unnoticed.
== Advantages of this approach ==
* Commons serves just about enough traffic to sometimes act as a useful
canary for performance/scaling issues that will later appear in production.
* Developers have some post-deployment time to fix issues highly specific
to the non-Wikipedia wikis (e.g. extensions & gadgets only deployed there)
rather than being distracted by firefighting on Wikipedia
== Some options ==
Option A: Change nothing. I've not heard from enough folks to see if the
problems above are widely perceived to _be_ problems. If the consensus is
that current practice, for now, is the best possible approach, obviously we
should stick with it.
Option B: No Monday deploy. This would mean we'd have to improve our
testing process to catch issues affecting the non-Wikipedia wikis before
they hit production. I personally think getting rid of the Monday deploy
could create some _desirable_ pain that would act as a forcing function to
improve pre-release test practices, rather than using production wikis to
test.
At the same time, we'd have a full week to work out the kinks we find in
testing before they hit any production wiki, and could have a more
systematic process of backing out changes if needed prior to deployment.
Option C: Shift Monday deploys to Tuesday. This would at least give us an
additional work day to fix issues that have occurred in testing before they
hit prod. I personally don't think this goes far enough, but might be a
useful tweak to make if option B seems too problematic.
Are there other ways to optimize / issues I'm missing or misrepresenting
above?
Thanks,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation