[Wikitech-l] CR on Scribunto

[Mark A. Hershberger via Wikitech-l]

Could I get a CR on
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1050721
??

I ran into the problem when I compiled my own version of lua to change
the version number[1], but the version number didn't show up on
Special:Version.  It turns out that `lua -v` is output on STDERR but
that wasn't captured.

Of course, if someone could look over my suggested patch to resolve
T366824[2], that would help, too.

Thanks!

Mark.

Footnotes:
[1]  https://phabricator.wikimedia.org/T366824

[2]  https://phabricator.wikimedia.org/T366824#9895800

-- 
http://hexmode.com/

Don't ask me who's influenced me. A lion is made up of the
lambs he's digested, and I've been reading all my life.
-- Giorgos Seferis
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: WikiApiary discussion tomorrow at #mwstake meeting

[Mark A. Hershberger via Wikitech-l]

All,

The time I originally posted was wrong.  I said tomorrow in the subject
and gave today's date in the body.

Corrected information:

Please join us on Google Meet: https://meet.google.com/mdd-ufhn-ksb
Time: 2 February 2024 16:30:00 (UTC)
Time conversion:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240202T1630


Apologies for the confusion.

Mark.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] WikiApiary discussion tomorrow at #mwstake meeting

[Mark A. Hershberger via Wikitech-l]

We (#mwstake) are talking about current progress on WikiApiary tomorrow.
You can see the current implementation here:
https://wikiapiary.wmcloud.org/wiki/

(Try the random button on the site since the front page is pretty dull
right now.)

Please join us on Google Meet: https://meet.google.com/mdd-ufhn-ksb
Time: 1 February 2024 16:30:00 (UTC)
Time conversion: 
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240201T1630

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Backported CirrusSearch for 1.35 ... is anyone else interested?

[Mark A. Hershberger]

Today, someone asked to see if I could get MediaWiki 1.35 to work with
ElasticSearch 7.x because they already had a licensed instance running
that they wanted to piggy back onto.

It wasn't too difficult to get CirrusSearch for 1.39 backported so that
I can at least get results from the search.  I haven't tested it too
much and I the unit tests aren't working, but this WORKSFORME, so far.

Is there anyone else interested in this?

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Help +2 php 8.1 updates

[Mark A. Hershberger via Wikitech-l]

MediaWiki devs,

I've been running the test suite using PHP 8.1 and providing patches in
Gerrit.  I've gotten some feedback but I am hoping that I can get the
requisite +2's to get these fixes incorporated into MediaWiki.

I have several patches outstanding with no comments.  If they could be
+2'd that would be awesome.

If they need more work before they're accepted, please let me know how
they are lacking so that I can update them.

Most of these can be found here:
https://gerrit.wikimedia.org/r/q/topic:change-809720

Thanks!

Mark.


-- 
http://hexmode.com/

I cannot remember the books I've read any more than the meals I have eaten;
even so, they have made me.
-- Ralph Waldo Emerson
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] #mwstake meeting: Verified Content and MWStake Components

[Mark A. Hershberger]

The MediaWiki Stakeholders will be hosting our monthly meeting tomorrow
and all are invited.

Time:   15:30:00UTC 11:30AM Eastern 8:30AM Pacific 17:30 CEST
Google Meet:https://meet.google.com/mdd-ufhn-ksb

Markus Glaser, of Hallo Welt!, will talk about "Verified content in
MediaWiki with blockchain":

In a project with inblock.io, Hallo Welt! explored the possibilities
of creating a verification chain for content and changes in
MediaWiki. Markus will talk about what they did.

Robert Vogel, also of Hallo Welt!, will introduce the MWStake
Components:

Learn about what the MWStake Components are, their origin and
purpose. Robert will share Hallo Welt!'s experience with this
approach and show how MWStake Components can be used in your own
projects.

Please join us!

Mark

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Marking the 600,000th commit on Wikimedia Gerrit

[Mark A. Hershberger via Wikitech-l]

James Forrester  writes:

> I wrote a quick post
> 
> celebrating that today, after nine years using Gerrit, we hit our 600,000th
> commit.

Nine years?

Man, I didn't realize so much time had passed.

I can't say I love gerrit, but I guess I've had nine year to get
comfortable with it.

Seems like a good time to switch everyone to Phabricator's Differential!

/s

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unstable search results - possible causes

[Mark A. Hershberger]

"Hogan (US), Michael C"  writes:

> It may matter that we're running the wiki on two servers, using
> Percona MySQL for data replication between the servers.

I'm guessing that this is the cause.

If you're using the XtraDB Cluster, you have probably set PXC Strict
Mode to permissive or disabled it and, as a result, there is some
inconsistency between the two databases.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dead Links

[Mark A. Hershberger]

ad...@gunsense.xyz writes:

> dead link: "You can also use the gmane web interface for reading AND
> posting to the list.
> http://news.gmane.org/gmane.science.linguistics.wikipedia.technical/;

GMANE's NNTP interface for reading mailing lists is still up (I'm using
it), but the NNTP posting is down,

It looks like the website itself is barely limping along.

It is probably time to update that information.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Stakeholders' meta-repository of extensions not in gerrit

[Mark A. Hershberger]

Niklas Laxström  writes:

> Why submodules?

Because that is my preference.  It provides a way to have a local copy
of extensions without a lot of work.

> Is someone planning to keep those up to date?

I would be happy to set up a daily cron job that could update these.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Stakeholders' meta-repository of extensions not in gerrit

[Mark A. Hershberger]

This afternoon, while procrastinating by cleaning up my clone of
gerrit's mediawiki extensions repository, I decided to make a meta
repository for some non-WMF-hosted extensions.  (Hopefully this will
mean less need to clean up the clone in the future.)

I got some low-hanging fruit to start it off, but I'm hoping I can get
some pull requests to add more repositories.

Check it out: https://github.com/MWStake/nonwmf-extensions

Thanks,

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Stakeholders' meta-repository of extensions not in gerrit

[Mark A. Hershberger]

This afternoon, while procrastinating by cleaning up my clone of
gerrit's mediawiki extensions repository, I decided to make a meta
repository for some non-WMF-hosted extensions.  (Hopefully this will
mean less need to clean up the clone in the future.)

I got some low-hanging fruit to start it off, but I'm hoping I can get
some pull requests to add more repositories.

Check it out: https://github.com/MWStake/nonwmf-extensions

Thanks,

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki pingback

[Mark A. Hershberger]

Ori Livneh <o...@wikimedia.org> writes:

> The plan is to make this data freely available to all MediaWiki developers.
> Before that can happen, I will need to solicit reviews from security folks
> and from the WMF's legal team, but I don't expect any major issues.
>
> Please chime in if you have any thoughts about this. :)

This is so freaking awesome.  Thanks for your work on this.

I'm sure I'll have other comments later.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Usage Report 2015

[Mark A. Hershberger]

Brian Wolff  writes:

> Umm, where is the link to the report?

Dadgummit.  Stupid mailmain filtering out HTML mail.

I'll resend.  Sorry for the confusion.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Usage Report 2015

[Mark A. Hershberger]

The MediaWiki Stakeholders' User Group wants to improve MediaWiki and advocates 
the needs of MediaWiki users outside Wikimedia Foundation-supported projects. 




But who is using MediaWiki? In an effort to answer this question the MediaWiki 
Stakeholders’ Group organized a survey during the summer of 2015 and asked 
people using MediaWiki to respond. The result is a sampling of over 100 
responses from people using MediaWiki around the world. The results were 
interesting. Folks from all sorts of communities and industries use MediaWiki - 
from organizations like NASA, The UK LGBT Archive, Society of Exploration 
Geophysicists, and more. 




Combined with some statistics we were able to obtain with help from individuals 
at the WMF, and the results of the survey we have completed our MediaWiki Usage 
Report for 2015 . This report provides insight into the various ways MediaWiki 
is being used - How people upgrade, what extensions are their "must have's", 
what they enjoy about the software, their concerns, and more. We encourage 
those using MediaWiki to have a look and provide any feedback or thoughts. 




If you'd like to know more about the MediaWiki Stakeholders' Group, or to get 
involved, join us for one of our regular hangouts or leave a note on our talk 
page . MediaWiki Wishlist 


Combined with existing collaboration around request features and responses from 
one particular survey question, "What would you like to see most improved in 
MediaWiki the software?" we created a prioritized 'wishlist' of MediaWiki 
features . Our next project is figuring out how to implement these requests. 
See Also 


* A raw download of the survey results (anonymized of course) can be found 
on MediaWiki.org 
* If you were at our session at Wikimania 2015, this might sound familiar. 
There we shared preliminary results from the survey while we were still 
collecting responses. 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Usage Report 2015

[Mark A. Hershberger]

TL;DR: https://www.mediawiki.org/wiki/MediaWiki_Usage_Report_2015

The MediaWiki Stakeholders User Group[1] wants to improve MediaWiki and
advocates the needs of MediaWiki users outside Wikimedia
Foundation-supported projects.

But who is using MediaWiki? In an effort to answer this question the
MediaWiki Stakeholders’ Group organized a survey[2] during the summer of
2015 and asked people using MediaWiki to respond. The result is a
sampling of over 100 responses from people using MediaWiki around the
world. The results were interesting. Folks from all sorts of communities
and industries use MediaWiki - from organizations like NASA, The UK LGBT
Archive, Society of Exploration Geophysicists, and more.

Combined with some statistics we were able to obtain with help from
individuals at the WMF, and the results of the survey we have completed
our MediaWiki Usage Report for 2015.[3] This report provides insight into
the various ways MediaWiki is being used - How people upgrade, what
extensions are their "must have's", what they enjoy about the software,
their concerns, and more. We encourage those using MediaWiki to have a
look and provide any feedback or thoughts.

If you'd like to know more about the MediaWiki Stakeholders Group, or
to get involved, join us for one of our regular hangouts or leave a note
on our talk page.[4]

MediaWiki Wishlist

Combined with existing collaboration around request features and
responses from one particular survey question, "What would you like to
see most improved in MediaWiki the software?" we created a prioritized
'wishlist' of MediaWiki features.[5] Our next project is figuring out how
to implement these requests.

See Also

* A raw download of the survey results (anonymized of course) can be
  found on MediaWiki.org.[6]

* If you were at our session at Wikimania 2015, this might sound
  familiar. There we shared preliminary results[7] from the survey while we
  were still collecting responses.

Footnotes: 
[1]  https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group

[2]  https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey

[3]  https://www.mediawiki.org/wiki/MediaWiki_Usage_Report_2015

[4]  https://www.mediawiki.org/wiki/Talk:MediaWiki_Stakeholders%27_Group

[5]  
https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Tasks/Feature_wishlist

[6]  
https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey/Survey_Results_Anonymized.csv

[7]  https://commons.wikimedia.org/wiki/File:2015_MediaWiki_User_Report.pdf


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Emacs for MediaWiki

[Mark A. Hershberger]

Hijacking a thread because this is something I've spent a lot of time
working on.

Tyler Romeo <tylerro...@gmail.com> writes:

> If I had the time, I would definitely put together some sort of
> .dir-locals.el for MediaWiki, that way we could make better use of Emacs,
> since it has a bunch of IDE-like functionality, even if it's not IDEA-level
> powerful.

A client wanted to me to help train someone to take over the work for
maintaining their MediaWiki installation.  As part of that work, they
asked for an IDE and, knowing that other MW devs used PHPStorm, I
recommended it and they bought a copy for me and the person I was
supposed to train.

PHPStorm has "emacs keybindings" but these are just replacements for the
CUA keybindings.  Somethings that I expected the keybindings to invoke,
didn't.  (It's been a while since I've used PHPStorm, so I've forgotten
the details.)

In any case, I've found that a lot of what I wanted from PHPStorm could
be implemented in Emacs using the following .dir-locals.el (which I put
above my core and extensions checkouts):

((nil . ((flycheck-phpcs-standard . ".../mediawiki/codesniffer/MediaWiki")
 (flycheck-phpmd-rulesets . 
(".../mediawiki/messdetector/phpmd-ruleset.xml"))
 (mode . flycheck)
 (magit-gerrit-ssh-creds  . "m...@gerrit.wikimedia.org")
 )))

The above is in addition to the code-sniffing I already had set up to
put Emacs' php-mode into the MW style.  You can see this documented on
[[mw:Manual:Coding_conventions]].

The one thing that PHPStorm lacked (and where Emacs' magit excels) is
dealing with git submodules.  Since I make extensive use of submodules
for my MediaWiki work, this set up makes Emacs a much better tool for
working with MediaWiki.

Naturally, I won't claim that what works for me will work for anyone
else.  I've spent 15 years in Emacs every day.  I was first exposed to
Emacs in the late 80s(!!) so the virus has had a long time to work its
way into my psyche and by now I'm incurable.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki user survey and un-reachable users

[Mark A. Hershberger]

Dan Garry dga...@wikimedia.org writes:

 Thanks for organising this survey! I saw that you posted results of the
 survey https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey#Results;
 thanks for that! I was wondering if you could summarise and share what
 you've learned about MediaWiki users from the survey.

I did plan on doing this but haven't had a chance to focus on it.  I'll
set a deadline for myself to have it out this week.

Thanks for the reminder,

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] extension updates for 1.23.x?

[Mark A. Hershberger]

Jim Tittsler j...@onjapan.net writes:

 What is the recommended path for updating extensions if you are still
 using the 1.23.x series?

Generally, extensions don't update their release branches.  Sometimes
you can use the latest from master's HEAD for an extension, but breaking
changes happen often enough in core that this can cause a problem.

If you want fixes back-ported to the LTS version, your best bet is to
talk to the extension's maintainer.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Standardizing extension development practices

[Mark A. Hershberger]

Bryan Davis bd...@wikimedia.org writes:

 On Tue, Jul 21, 2015 at 5:42 PM, Jeroen De Dauw jeroended...@gmail.com 
 wrote:
 What exactly justifies such an authoritarian need to go though some
 permission process setup? Exactly what problems are we currently
 seeing?

 I would certainly welcome an RfC discussion of the current policy and
 a potential replacement. From my point of view, use of the MediaWiki
 brand implies endorsement by the MediaWiki community and thus should
 only be easily available to projects that are able to be contributed
 to and managed by that community. If for example a serious security
 flaw was found in a mediawiki/foo package on Packagist the community
 should be empowered to fix it.

This discussion is at least tangentially related to the IdeaLab project
that Chris Koerner and I formulated at Wikimania:

https://meta.wikimedia.org/wiki/Grants:IdeaLab/Making_Gerrit_access_easier_for_developers_new_to_MediaWiki

There are benefits to using the Gerrit.w.o -- the git repository that
most MW-experienced developers are using, and where they have rights to
upgrade code (e.g. the i18n conversion to json) -- instead of Github,
Assembla, Kiln, or Bitbucket.

We've done a poor job of explaining the benefits, though, and, more than
that, providing an infrastructure that developers not deeply involved
with the WMF can use, though.

I invite your comments on the IdeaLab proposal page.  Maybe it means
improving MediaWiki support for developers on GitHub, but if that is the
route we go, then we need to figure out a way to do that.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki user survey and un-reachable users

[Mark A. Hershberger]

bawolff bawolff...@gmail.com writes:

 Can we add a link to the survey to the top of
 https://www.mediawiki.org/wiki/Download until the end of July?


 Sounds reasonable. I added a link to the top of that page.

Thanks!  You did a better job than I would have.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki user survey and un-reachable users

[Mark A. Hershberger]

We haven't announced this survey on wikitech-l yet, so if you run a wiki
outside of those run by the WMF, please take the time to fill out the
survey at http://hexm.de/MWSurvey.  More information about the survey
and its purpose can be found at
https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey.

That said, we received a report (T104010) from the Analytics team today
that most downloads of MediaWiki are coming from China.  The report
indicated there were twice as many downloads from China as the U.S. in
June.

I don't know of a good way to reach these users -- I wasn't even aware
of them till today.  Through our efforts at outreach so far we've
uncovered a number of private wikis that we wouldn't have been able to
discover otherwise, but I'd like to extend our reach even farther.

Can we add a link to the survey to the top of
https://www.mediawiki.org/wiki/Download until the end of July?

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE stopped working on 1.25 after import update of wiki db (1.23-1.25)

[Mark A. Hershberger]

Daren Welsh darenwe...@gmail.com writes:

 There's nothing in the console.

Have you tried looking at the responses from parsoid?  By the way, even
though Parsoid isn't versioned the same way, you might be able to use
the latest from git master.

The other thing to try (I don't recall ATM if this is actually needed)
is composer update.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki needs a governance model

[Mark A. Hershberger]

I just posted this at http://mwstake.org/mwstake/wiki/Blog_Post:18 and I
would like to invite your comments.

= MediaWiki needs a governance model =
Eighteen months ago, at the 
[https://www.mediawiki.org/wiki/Architecture_Summit_2014 MediaWiki Architecture 
Summit], a manager from Wikia said, repeatedly, that he was there to find out 
where MediaWiki was going to be in five years.

This year, at the 
[https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015 MediaWiki 
Developer's Summit], Damion Sicore, the new VP of Engineering for Wikimedia, 
asked about MediaWiki's governance model.

Both these people were relative outsiders to the core of MediaWiki development 
and both of them described the same problem: MediaWiki doesn't have direction.

During the [https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015 Wikimedia 
Hackathon] this year, I cornered Damon and asked him what he thought needed to 
be done.  After some back-and-forth, Damon said that if we could come up with a 
governance model for MediaWiki that the stakeholders would endorse, that would 
be a great start.

I only had two questions: What was a governance model? And, could I get the 
stakeholders for MediaWiki to buy into one?

== Stakeholders ==
This past year Markus Glaser and I started the 
[https://www.mediawiki.org/wiki/MediaWiki_Stakeholders'_Group MediaWiki 
Stakeholders] user group.  This is a group of people interested in MediaWiki as 
software because we use it in our businesses and organisations.  We want to 
have a voice in its development.

We do have issues #x2013; some of the most visible users of MediaWiki, such as 
Wikia and WikiHow #x2013; are not involved #x2013; but we've also had some 
really good successes that we can point to, like our 
[http://mwstake.org/mwstake/wiki/Category:Events monthly meetings], our 
[http://mwstake.org/ own wiki], and the meeting at the Wikimedia Hackathon this 
spring.

If you use MediaWiki for your own projects and you're interested in the future 
of the software, we ask you to [http://mwstake.org join us].  We especially 
need your involvement if you are a large, visible user of MediaWiki like Wikia 
or WikiHow.

== Governance ==
That brings me to the first, less intuitive, question: What is a governance 
model?  Why is it needed?

Research done on 
[https://blog.wikimedia.org/2015/06/28/research-newsletter-june-2015/#How_Wikipedia_built_governance_capability.2C_2001.E2.80.932009
 Wikipedia's governance model] is instructive. Online social production is 
contrasted with traditional, contract-bound, hierarchical production models 
that characterize most organizational settings.  Despite this contrast with 
traditional production, Wikipedia's governance model is becoming less open and 
more codified#x2026;a positive change.

Indeed, Wikipedia and MediaWiki are closely related but they cannot share 
governance models since [https://wikiapiary.com/wiki/Main_Page most MediaWiki 
installations] are outside of the Wikimedia Foundation, and, as a result 
MediaWiki development cannot be driven only by the needs of the Foundation.

Instead, we need to begin to use the governance model to separate its 
development from the Foundation and establish it as an independent open source 
software product.

As a result, we need to start looking at MediaWiki development in the context 
of the larger world of open source software. The [http://oss-watch.ac.uk/ OSS 
Watch] [http://wiki.oss-watch.ac.uk/StartPage Wiki] has a lot of relevant 
information about how open source software projects are run. See, for example, 
the explanation given on the [http://wiki.oss-watch.ac.uk/GovernanceModel 
GovernanceModel] page:

A clear governance model allows potential contributors to understand how they 
engage with the project, what is expected of them and what protections are 
provided to ensure their contributions will always be available to them. It 
also describes the quality control processes that help assure potential users 
of the viability of the project.
''[#x2026;]''
[Governance] provides a mechanism for allowing the community as a whole to 
define the direction they feel the project should take, '''while ensuring that 
the core project team does not lose control'''.

== Why does the MediaWiki community need to do anything?  What is wrong with 
the status quo? ==
Now, some members of the MediaWiki developer community will not see a need for 
such a model.  Indeed, they'll tell you there is already one in place.

One problem is that this model is only sporadically documented and isn't well 
communicated.  So each person in the community ''thinks'' they know what the 
rules of the game are, but their individual models can differ drastically.

Another problem, especially when it comes to features of MediaWiki that are not 
used on Wikipedia, is that it is developer-focused instead of user-focused.

For example, if you've used MediaWiki's built-in hitcounter in the past, you'll 
be 

Re: [Wikitech-l] MediaWiki needs a governance model

[Mark A. Hershberger]

Brian,

Thanks for your reply.  I only have a couple of comments.

Brian Wolff bawo...@gmail.com writes:

 On 7/1/15, Mark A. Hershberger m...@nichework.com wrote:
 Instead, we need to begin to use the governance model to separate its
 development from the Foundation and establish it as an independent open
 source software product.

 I'm not sure I'd phrase that like that. I would like all potential
 developers to be able to develop MediaWiki and influence its
 development to the same extent, regardless of their affiliation.

I like the way you've phrased this.

The one change I would make is to de-emphasize developers by replacing
all potential developers to be able to develop MediaWiki with all
users of MediaWiki to be able to shape MediaWiki.

 * How will governance be enforced? How will things change?

 Which presupposes that the governance model will enforce things. Will
 the governance model be enforcing things, and which things will be
 in its remit are probably questions that should be asked first.

I agree.  enforced is too strong for anything proposed so far (which
is simply that we need a governance model).  I was just trying to bring
up questions that would arise.

Thanks again for your comments,

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Jenkins slaves now use tmpfs for MySQL storage

[Mark A. Hershberger]

Krinkle krinklem...@gmail.com writes:

 Our average build time went from 20 minutes (zend) and 8 minutes
 (hhvm) to 9 minutes and 4 minutes!

Nice.  Very nice.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] post project funding

[Mark A. Hershberger]

Brian Wolff bawo...@gmail.com writes:

 Politically, I think its dangerous how WMF seems to more and more
 become the only stakeholder in MediaWiki development.

We do have the MediaWiki Stakeholders group.  The people involved there
would argue that they have funded MediaWiki-focused development.

The WMF is the 600 pound gorilla, though.  And the lack of leadership (a
central topic at the recent developer summit) doesn't help.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Adopting Composer's composer.json for extensions

[Mark A. Hershberger]

I've opened a task on Phabricator[1] to attempt to merge the information
in extension.json with Composer's
already-used-by-several-extensions-and-skins composer.json.

Kunal has rightly pointed out that composer doesn't fit some use-cases
for MediaWiki.  I see that as an opportunity to be good citizens in the
larger developer community by working to integrate MediaWiki into the
growing ecosystem available on packagist.org.

For example, if composer had been available, we might not have had to
develop our own HTTP client.

If composer had been available, Brion could have released the work under
includes/normal as its own package.  As he says in the README there:

This directory contains some Unicode normalization routines. These
routines are meant to be reusable in other projects, so I'm not
tying them to the MediaWiki utility functions.

(Of course, there was PEAR, but that is ugly and centralized in a way
that composer is not.)

Using Composer for extensions also reduces the learning curve for
developers who want to adapt their work (which may already be available
via Composer) to be used in MediaWiki.  It helps us increase the size of
the available developer community without too much effort.

Footnotes: 
[1]  https://phabricator.wikimedia.org/T89456

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Adopting Composer's composer.json for extensions

[Mark A. Hershberger]

Legoktm legoktm.wikipe...@gmail.com writes:

 Can we please centralize this discussion? We're discussing this
 on-wiki, and now it's spread to Phabricator and wikitech-l.

I apologize for the diffusion.

I'm trying to get attention on this issue, but obviously I've
overstepped.  I'm fine with continuing on-wiki and in the RFC discussion
that is planned.

I'll restrict my response here.

 For example, if composer had been available, we might not have had to
 develop our own HTTP client.

 I don't buy this argument. If there had been code available for us to
 use and there was an advantage to using it instead of writing our own,
 we probably would have just copied it into core like we have done with
 other PHP code in includes/libs/.

Since I did some work on the HTTP client, I like to think I have some
insight.  We wouldn't have copied the other code into includes/libs
since that didn't exist at the time.  The PEAR module existed, but we
had already begun developing our own very lightweight client at that
time that I started working on it.

At the time that I started working on it, the PEAR module looked too
heavyweight.  Maybe it is re-evaluate the code to use.

It is good to see that we've begun making the code we produce more
sharable, so thanks for your help there, Kunal.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] All Hands On Deck!

[Mark A. Hershberger]

Antoine Musso hashar+...@free.fr writes:

 Le 23/01/2015 09:11, littlewmfb...@yandex.com a écrit :
 Oh what a day! Which began when perforce
 a visitor from afar began to exhort
 snip
 https://lists.wikimedia.org/pipermail/wikitech-l/2015-January/080300.html

 Can we get a simple English version of the poetry there?

As others have pointed out poetry doesn't translate well, but I've
managed to come up with an interpretation that I hope is easy for a
non-native speaker to understand.

(I admit feeling safer doing this since I wasn't at the all staff and
have no clue what this is about.  Burn me at the stake later.)

--- begin ---
What a day it has been!  We had an outside speaker who told us to
a lot of feel-good things -- learn, travel, see new things.

So we walked around San Francisco and talked to each other about
ourselves.

What a relief that we didn't *really* have to consider new thoughts or
ways of seeing things.

This made us feel great despite some obvious things like problems with
our projects and our horrible user experience that seems to ignore the
last 10 years of the Social Web and dissatisfied users who write long
rants.

Next we talked about strategy and new people without experience in the
project told us everything we had done wrong.

Three commands we were given:
1. Be fast *and* correct!
(But this seems to ignore reality of how long it takes to create
correct code.)

2. Innovate!
(As a pessimist, I don't see this as being in line with the
conservative nature of our current users and new editors and processes
don't just appear.)

3. Integrate, engage with the community
(But this seems to assume that there is a cohesive community instead
of the enormous conflicts and chaos that looks like the reality.  They
told us to engage with the community, but this didn't seem to recognize
the times we we've tried and got beat up by the community.)

In the end, we'll probably just end up doing our job like we have been.
--- end ---

Hope that is helpful,

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application

[Mark A. Hershberger]

Petr Bena benap...@gmail.com writes:

 web-app for offline use? :o

Maybe they have a small webserver set up in a remote place with only
sporadic Internet access?  Maybe they're running a Mozilla's Firefox OS
on a phone and calling apps for that OS web apps?

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application

[Mark A. Hershberger]

Petr Bena benap...@gmail.com writes:

 That suck. Especially with GPRS internet and similar connectivity and
 it also suck because mobile phones don't even have space for so much
 data. My idea is to create app similar to kiwix, that would use SQLite
 DB and using wikipedia API it would (slowly, apache friendly) download
 contents of any mediawiki installation based on user selection, so
 that you could download just a 1 page for offline reading, or 1
 category. Or 1000 categories. Or precompiled sets of pages created by
 users (books). You could easily update these using API anytime to
 latest version. You could get media files for these pages, etc, etc...
 (You could probably even edit the pages offline, and then update them
 when you are online, but that is just extra feature)

Also see the application that WikiEM (Emergency Medicine) is working on.
Dan Ostermayer (CC'd -- Link to original[1]) recently applied for a PEG
Grant[2] to continue development on their non-Kiwix alternative for
offline Wiki reading[3].

They didn't get a grant, but, from past conversations with
Mr. Ostermayer, I understand that content from WikiEM is already being
used offline in the Emergency Room and he will continue work on this by
getting funding elsewhere.

If nothing else, this would probably be a good place to start.

Mark.

Footnotes: 
[1]  
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/81173

[2]  
https://meta.wikimedia.org/wiki/Grants:PEG/Offline_MediaWiki_search_for_NASA_and_Medicine

[3]  https://github.com/ostermayer/offlinexml

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Mark A. Hershberger]

Quim Gil q...@wikimedia.org writes:

 Can we please discuss the idea of nominating architects per area? Is
 there any good reason not to do it?

There is no good reason not to do this.  We should do it.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Mark A. Hershberger]

Tyler Romeo tylerro...@gmail.com writes:

 Just because they hire the “best and the brightest” does not mean
 there are not people out there who are just as intelligent, if not
 more, but do not or cannot work for the WMF for whatever
 reason. Restricting Archcom to WMF employees is just about the
 stupidest thing you could do for an open source software project.

Exactly.  It ensures that those of us using or supporting MediaWiki
outside of the WMF have no voice in the direction of MW.

I am not qualified for the ArchCom, but I am familiar with several
engineers working in government or running private wiki farms or their
own businesses who I think would be qualified.

I think the WMF has hired the people it can hire, but that doesn't mean
all ArchCom-level knowledge is found only in Foundation employees.

Thinking that only the WMF has high-level MW knowledge and ability is a
myopic view that threatens the future of MediaWiki as software that is
useful outside of the WMF.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wfRunHooks deprecation

[Mark A. Hershberger]

Legoktm legoktm.wikipe...@gmail.com writes:

 On 01/21/2015 09:39 AM, Jeroen De Dauw wrote:
 Hey,
 
 Does the new syntax offer any advantage over the old one?

 It's a little bit faster by cutting down one function call which adds up
 when a lot of hooks are called.

adds up is a poor defense for creating work for end users and
developers.  Has anyone actually measured what the difference is or is
this just an example of premature optimization[1]?

Mark.

Footnotes: 
[1]  http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE without Parsoid

[Mark A. Hershberger]

James Forrester jforres...@wikimedia.org writes:

 There's also #3 – doing all the dozens of things that the wikitext parser
 does on ingestion. All the redlinks and categories tables, ​building a
 user-land (not UI) HTML template system for transclusions, media updates,
 *etc.* Not a trivial task.

If I'm not mistaken, the MW Parser already does thos and Parsoid relies
on MW for this.

So assuming we can go from Wikitext - HTML (we already can) and
HTML - Wikitext (which is, AFAICT, what we would need a PHP
implementation of) then we're golden!

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Mark A. Hershberger]

Quim Gil q...@wikimedia.org writes:

 We need a healthy MediaWiki open source software project in the first
 place. Without this, no committee, dictator or CTO will save the project in
 the long run.

Agreed.

 While the Wikimedia Foundation plays a key role in the development of
 MediaWiki, the structure of the open source project must be driven by
 community merit. The MediaWiki platform roadmap should be discussed and
 agreed at a community level.

Thank you for saying this.

You also re-iterated Tim's point about ArchCom's powerlessness and
pointed to some ways to address that.

I would also suggest that an effort be made to find community members
who are not WMF employees to participate in the ArchCom and then to have
their voices heard during in quarterly planning.

You also suggested that we [identify] key MediaWiki platform areas and
their architects / maintainers.

If we look at the whole MW ecosystem, I sure we'll find that some key
platform areas have maintainers who are not WMF employees.

Mark.


-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] VE without Parsoid

[Mark A. Hershberger]

Tim Starling tstarl...@wikimedia.org writes:

 HTML storage would be a pretty simple feature, and would allow
 third-party users to use VE without Parsoid.

I've been thinking about how to implement an alternative to Parsoid
so that users of MW could use VE without standing up a node.js server.

This gives me hope.

Could anyone elaborate on what VE needs from MW in order to operate
without Parsoid?  Maybe there is an architecture diagram I've been
missing?

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of shared hosting

[Mark A. Hershberger]

MZMcBride z...@mzmcbride.com writes:

 We should be proud of how popular MediaWiki has become across the
 Internet and we should support its growth because it ultimately
 supports our own. The more people engaged with and using MediaWiki,
 the better off we are.

Thank you for this.  I agree whole heartedly.  I'd like to see what we
can do to increase its usage.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Mark A. Hershberger]

Ori Livneh o...@wikimedia.org writes:

 The model I do think we should consider is Python 3. Python 3 did not
 jettison the Python 2 codebase. The intent behind the major version change
 was to open up a parallel development track in which it was permissible to
 break backward-compatibility in the name of making a substantial
 contribution to the coherence, elegance and utility of the language.

I like the idea, but this makes it sound like we have some commitment
in the current co-debase to backwards compatibility.

Currently, though, just as Robla points out that there is no clear
vision for the future, there is no clear mandate to support interfaces,
or what we usually call backwards compatibility.

So, yes, let's have a parallel MW 2.0 development track that will allow
developers to try out new things.  But let that be accompanied with a MW
1.0 track so that makes stability a priority.

Now, the question is: what will Wikipedia run: MW 2.0 or MW 1.0?  And,
if they focus on MW 2.0 (My sense is that is where the WMF devs will
want to be), then how do those of us with more conservative clients keep
MW 1.0 viable?

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of shared hosting

[Mark A. Hershberger]

Trevor Parscal tpars...@wikimedia.org writes:

 95% is pretty extreme.

Not according to WikiApiary.  The largest host for wikis, even before
Wikimedia, is DreamHost followed closely by GoDaddy and other shared
hosters such as 11.[1]

Yes, Amazon and Linode are also near the top of the list, but from
experience, I can tell you that most of those aren't using anything but
PHP, and, if you're lucky, the Math and Scribunto extensions.

Even the most asked-for service of the SOA -- Parsoid for Visual Editor
-- is almost (but not quite) exclusively on WMF wikis.[2]

Developers within an organisation like the WMF don't have to worry about
what it takes to stand up and maintain a wiki -- they have Operations
for that.

Most people running wikis based on MediaWiki don't have a budget or a
staff exclusively for their wiki.  They don't have the resources or
knowledge to run a dedicated server.

There are things that can be done to address this -- make it easier to
set up a SOA-using wiki on your chosen virtual machine provider -- but
they need dedicated resources.

This probably means a really dedicated (group of) volunteer(s) or a new
focus on non-WMF use of MediaWiki by the WMF.  This seems to be the
direct result of the the decisions made by developers who've implemented
some very compelling features without (as Robla seemed to say recently)
any overall architectural direction.

Mark.



Footnotes: 
[1]  https://wikiapiary.com/wiki/Host:Hosts

[2]  https://wikiapiary.com/wiki/Extension:VisualEditor

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Mark A. Hershberger]

Brian Wolff bawo...@gmail.com writes:

 Does anyone actually have anything they want that is difficult to do
 currently and requires a mass compat break?

I haven't heard of any mass compat break items.  But I have seen
developers who aren't worried about compatibility or continuity of
features since they only have to worry about the WMF cluster and issues
of compatibility are handled there, or the features aren't used by the
WMF.


-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Requests for comment process

[Mark A. Hershberger]

MZMcBride z...@mzmcbride.com writes:

 While the latter is not an unusual model, I personally don't think a
 strict approach is a well-fitting model for Wikimedia development. :-)

I don't disagree.

I think the confusion comes in because when I see an RFC process, I see
a formal process.

Perhaps I'm the only one confused in this way, but it would help to
rename the RFC process to something like A way to get your ideas
reviewed by the community, but totally not necessary.  You can always
just submit patches and see if it is accepted.

But that is probably too unwieldy.

I didn't think it was necessary to put the specification in the RFC
namespace since the RFC was accepted.

 It's certainly not uncommon to simply throw pages in the main namespace on
 mediawiki.org. We all do it occasionally. However, doing so makes it less
 likely for others to find your page. Using the RFC structure (page title
 prefix, infobox template, categories) makes it marginally more likely that
 others might find and read your page.

Wouldn't linking them all together serve the same purpose?  That way, if
someone finds the RFC and sees links to a specification (regardless of
the pseudo namespace) and, hopefully, an implementation, they could get
all this information.

 One anti-pattern that I'm concerned with is that RFCs often do not have
 associated discussion or related pages attached to them.

Agreed.  I need to spend time linking this all together.

 I've been thinking that a checklist might help the meetings run more
 smoothly.

I'm a big fan of checklists.  They provide an easy answer to I didn't
know I was supposed to do that.  And they help keep things organized by
providing a uniform set of expectations for us.

Mark.


-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Spec for opt-in site registration RFC

[Mark A. Hershberger]

MZMcBride z...@mzmcbride.com writes:

https://www.mediawiki.org/wiki/Version_check_and_opt-in_site_reporting.

 Is there a reason you used the main article namespace instead of the
 Requests for comment/ pseudo-namespace? Your e-mail subject line says
 RFC and this new page follows a previous RFC (Opt-in site registration
 during installation), which makes the page title seem a bit strange.

This is a spec for a feature that was discussed in an RFC.  Maybe I'm
missing something about the process, but my impression was that the RFC
was accepted and now all that is remaining is implementation.

I didn't think it was necessary to put the specification in the RFC
namespace since the RFC was accepted.

If I've misunderstood the process, I'll correct my mistake.

Have I misunderstood the process?

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Spec for opt-in site registration RFC

[Mark A. Hershberger]

I've published this at 
https://www.mediawiki.org/wiki/Version_check_and_opt-in_site_reporting.

Please comment on the talk page.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Spec for opt-in MediaWiki registration coming

[Mark A. Hershberger]

As a result of the Opt-In RFC[1] and discussion in the RFC meeting earlier this 
month[2], I will be presenting a draft specification for the feature before the 
end of the new year.

Please see the meeting summary for an overview of what was agreed[3].  I will 
need (even if I don't remember to request it) some design help for this 
feature, so lots of comments are encouraged and desired.

[1]  
https://www.mediawiki.org/wiki/Requests_for_comment/Opt-in_site_registration_during_installation
[2]  
http://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-12-03-20.58.log.html#l-168
[3]  
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-12-03#Meeting_summary

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Final RC for 1.24

[Mark A. Hershberger]

Matthew Flaschen mflasc...@wikimedia.org writes:

 This brings up a question.  Where is the code that builds the tarball?

The script is make-release/make-release.py in the
mediawiki/tools/release[1] repository.

I've updated the Release checklist[2] with this information.

Mark.

Footnotes: 
[1]  http://git.wikimedia.org/tree/mediawiki%2Ftools%2Frelease.git

[2]  https://www.mediawiki.org/wiki/Release_checklist

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Final RC for 1.24

[Mark A. Hershberger]

Based on the feedback, it seems obvious that we will have to go with the
previous RC for the release.

Legoktm: You're right when you ask where is the bug for this?  The
feedback and interaction happened mostly on Twitter and Skype.  I should
have asked Jamie to file a bug.

More below.

James HK jamesin.hongkon...@gmail.com writes:

 Despite this, I think we should stick to the `composer.json` and for
 users that already have a `composer.json` in place make sure that they
 migrate the content so that they don't loose any package by simply
 replacing the file.

In order to avoid causing too much confusion for those users who have
already used composer to install the latest Semantic MediaWiki, we'll
have to put an obvious notice in the announcement.

 In future, if changes are required to the `composer.json`, please
 merge instead of a simple replace and keep the user free from pain.

Are you willing to help modify the installer to help with this?

Mark.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Composer and the end user of MediaWiki

[Mark A. Hershberger]

SMW's introduction of Composer for installation has provided us with
real world examples of how the average person who installs a wiki
responds when faced with using composer.[1][2][3]

The response leads me to think that Composer is a great tool for
developers, but a horrible tool for end users.

This is frustrating because it takes care of versioning, dependency
management and installation.

Is there any app (desktop, web-based, or even mobile) that we could
point users to so that they could handle composer-based software
management without the frustration that we are currently seeing?

Footnotes: 
[1]  http://article.gmane.org/gmane.comp.web.wiki.semediawiki.user/15429

[2]  http://article.gmane.org/gmane.comp.web.wiki.semediawiki.user/17216

[3]  http://article.gmane.org/gmane.comp.web.wiki.semediawiki.user/17203

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Final RC for 1.24

[Mark A. Hershberger]

Hello everyone,

I am happy to announce the final release candidate for MediaWiki 1.24.0.
Download links are given at the end of this email.  There won't be any
more RC candidates before a final release on Wednesday unless someone
finds a really critical error.

== Changes since 1.24.0-rc.2 ==
* The composer.json file has been renamed to composer.json.sample after
  Jamie Thingelstad reported that his composer.json was overwritten by
  the tarball.

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.24.0-rc.3
**
Download:
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.3.tar.gz
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.3.tar.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.3.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.3.tar.gz.sig

Mark A. Hershberger
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Release candidate for 1.24.0

[Mark A. Hershberger]

Hello everyone,

I am happy to announce the (hopefully) final release candidate for
MediaWiki 1.24.0.  Download links are given at the end of this email.

== Changes since 1.24.0-rc.1 ==
* Setting $wgAllowSiteCSSOnRestrictedPages to true is necessary if you
  want to use on-wiki CSS modifications (e.g MediaWiki:Common.css) on
  Special:UserLogin or Special:Preferences.

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.24.0-rc.2
**
Download:
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.2.tar.gz
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.2.tar.gz

GPG signatures:
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.2.tar.gz.sig
http://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.2.tar.gz.sig


Mark A. Hershberger
(Release Management Team)

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] No release candidate this week for 1.24.0

[Mark A. Hershberger]

I had scheduled today for the third release candidate for 1.24.0, but
there is nothing new that has been merged or that, as far as I can see,
is ready to be merged for 1.24.0.

Next Friday will be the final RC for 1.24.0 with the actual 1.24.0
release on November 26th, the Wednesday before the Thanksgiving holiday
in U.S.

As a reminder, here are the bugs that are targeted for 1.24.0 that I
published earlier this week.

duplicate key in unittest_updatelog
http://bugzilla.wikimedia.org/71087

Specify default language on a per-page basis
http://bugzilla.wikimedia.org/9360

Special:PageLanguage does not tag page html output correctly
http://bugzilla.wikimedia.org/72940

Fix Uncommitted DB writes (transaction from DatabaseBase::query)
http://bugzilla.wikimedia.org/56269

[[mediawiki:sidebar]] no longer supports entirely numeric headers
http://bugzilla.wikimedia.org/71639

Missing defaults in GUI installer
http://bugzilla.wikimedia.org/69281

mw.trackSubscribe should prevent infinite recursion
http://bugzilla.wikimedia.org/67481

Import of Commons partial export fails with error about
plurals-mediawiki.xml
http://bugzilla.wikimedia.org/56439

Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not
available right after installation
http://bugzilla.wikimedia.org/70222

Improve JSONContent before releasing 1.24
http://bugzilla.wikimedia.org/70832

BagOStuff should behave consistently with regards to integer values
http://bugzilla.wikimedia.org/60563

Thanks,

Mark A. Hershberger
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Recognition of the MediaWiki Stakeholder's Group

[Mark A. Hershberger]

Quim Gil q...@wikimedia.org writes:

 PS: Stakeholder's or Stakeholders?

I did send Gregory an email shortly after he notified me that we were
accepted when the problematic apostrophe was pointed out to me.

We'd like to have the apostrophe removed, if possible.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recognition of the MediaWiki Stakeholder's Group

[Mark A. Hershberger]

Gregory Varnum writes:

 We have updated everything to reflect the correct spelling. Although it
 sounds like now you'd like no apostrophe?

Yes.

I apologize for the confusion and extra work.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Status of 1.24.0

[Mark A. Hershberger]

We've put out two release candidates for 1.24.0.  This week I'll be
releasing a third, so I thought I would point out all the open bugs that
have been targeted to 1.24.0.

duplicate key in unittest_updatelog
http://bugzilla.wikimedia.org/71087

Specify default language on a per-page basis
http://bugzilla.wikimedia.org/9360

Special:PageLanguage does not tag page html output correctly
http://bugzilla.wikimedia.org/72940

Fix Uncommitted DB writes (transaction from DatabaseBase::query)
http://bugzilla.wikimedia.org/56269

[[mediawiki:sidebar]] no longer supports entirely numeric headers
http://bugzilla.wikimedia.org/71639

Missing defaults in GUI installer
http://bugzilla.wikimedia.org/69281

mw.trackSubscribe should prevent infinite recursion
http://bugzilla.wikimedia.org/67481

Import of Commons partial export fails with error about
plurals-mediawiki.xml
http://bugzilla.wikimedia.org/56439

Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not
available right after installation
http://bugzilla.wikimedia.org/70222

Improve JSONContent before releasing 1.24
http://bugzilla.wikimedia.org/70832

BagOStuff should behave consistently with regards to integer values
http://bugzilla.wikimedia.org/60563

Mark.
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Second release candidate for MediaWiki 1.24.0

[Mark A. Hershberger]

The second release candidate for 1.24.0 (1.24.0-rc.1) is now available for 
download.

The changes since 1.24.0-rc.0 are as follows:

* (bug 70686) More sensible behavior when special page aliases conflict.
* (bug 71040) Add Oracle version of update-keys.sql.
* (bug 64912, 64922) mw.Title: Add new static methods `newFromFileName`,
  `newFromUserInput`.
* MediaWikiVersionFetcher::fetchVersion() now supports semantic versions.

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.24.0-rc.1/RELEASE-NOTES-1.24
https://www.mediawiki.org/wiki/Release_notes/1.24

**

Download:
http://download.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.1.tar.gz
http://download.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.1.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.1.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.1.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Mark A. Hershberger
(Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Mark A. Hershberger]

TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
release it with MediaWiki 1.24?

A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to
customize the appearance of their site.

In a recent security release[1], support for JS and CSS with on-wiki
origins was removed from being displayed on the Special:Login and
Special:Preferences page.

Because of how the on-wiki MediaWiki:Common.* pages are used and the
access restrictions on them, I think it is reasonable to allow JS and
CSS from them while continuing to disallow individual's JS and CSS on
the Special:Preferences and Special:Login page.

Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow
site-wide styling back on those pages.

I'd like to merge this, but I want some input from the community and
security people before I do that.

Thanks,

Mark.

(Reply-to set to mediawiki-l.)


Footnotes: 
[1]  https://bugzilla.wikimedia.org/70672

[2]  https://bugzilla.wikimedia.org/71621

[3]  https://gerrit.wikimedia.org/r/#/c/165979/


-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Mark A. Hershberger]

Derric Atzrott datzr...@alizeepathology.com writes:

 TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
 release it with MediaWiki 1.24?

 This seems completely reasonable to me. I'd merge is personally.  Is there
 any reason not to?

The discussion on the bug and the fact that this was in a security
release.

I'll merge it tomorrow for RC.1 unless someone objects or a problem
arises.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Including security fixes in MediaWiki

[Mark A. Hershberger]

Brian Wolff bawo...@gmail.com writes:

 From the list:
  Check for vulnerabilities

 That could use clarification...

https://phabricator.wikimedia.org/T1076

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Including security fixes in MediaWiki

[Mark A. Hershberger]

After some discussion in September, Quim created T480 in Phabricator[1].
Markus polished up the Security Release section of the Release
checklist[2] and we agreed to use it as the process for security
releases from now on.

Footnotes: 
[1]  https://phabricator.wikimedia.org/T480

[2]  
https://www.mediawiki.org/wiki/Release_checklist#Security_Release_.28minor_version_release.29

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] First 1.24 release candidate

[Mark A. Hershberger]

Hello everyone,

I would like to announce the first 1.24 release candidate.  Release
candidates are intended to provide you with an opportunity to test a
release and let us know of any problems that you encounter that should
be fixed before a final release.

Download links are given at the end of this email.

Release notes for 1.24:
https://www.mediawiki.org/wiki/Release_notes/1.24

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.24
**
Download:
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.0.tar.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-core-1.24.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.24/mediawiki-1.24.0-rc.0.patch.gz.sig

Mark A. Hershberger
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.23.6, 1.22.13 and 1.19.21

[Mark A. Hershberger]

Hello everyone,

I would like to announce the release of MediaWiki 1.23.6, 1.22.13 and
1.19.21.  These are regular maintenance releases. Download links are
given at the end of this email.

== Bugfixes in 1.23.6 ==
* (Bug 67440) Allow classes to be registered properly from installer
* (Bug 72274) Job queue not running (HTTP 411) due to missing
  Content-Length: header

== Bugfixes in 1.22.12 ==
* (Bug 67440) Allow classes to be registered properly from installer

== Bugfixes in 1.19.21 ==
* (bug 67440) Allow classes to be registered properly from installer.
* (bug 47281) Fixed a dumpBackup.php error with --uploads --include-files
  options: Unable to find the wrapper mwstore.
  System administrators are encouraged to upgrade to this release or 1.22+
  and produce a full data dump.
  https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Backing_up_a_wiki
* (bug 63049) Removed anonymous functions from ApiFormatBase, added in
  1.19.13 as part of the fix for bug 61362, for PHP 5.2 compatibility.

Full release notes for 1.23.6:
https://www.mediawiki.org/wiki/Release_notes/1.23

Full release notes for 1.22.13:
https://www.mediawiki.org/wiki/Release_notes/1.22

Full release notes for 1.19.21:
https://www.mediawiki.org/wiki/Release_notes/1.19

Public keys:
https://www.mediawiki.org/keys/keys.html

**
1.23.6
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.6.tar.gz
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.6.tar.gz

Patch to previous version (1.23.5):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.6.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.6.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.6.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.6.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.22.13
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.13.tar.gz
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.13.tar.gz

Patch to previous version (1.22.12):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.13.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.13.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.13.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.13.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


**
1.19.21
**
Download:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.21.tar.gz
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.21.tar.gz

Patch to previous version (1.19.20):
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.21.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.21.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.21.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.21.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Mark A. Hershberger
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Correction to prior announcement

[Mark A. Hershberger]

Hello everyone,

The prior maintenance release announcement email titled

MediaWiki Security and Maintenance Releases: 1.23.6, 1.22.13 and 1.19.21

included the word Security in the subject.  This inclusion was a
mistake.  There are no security fixes included in these releases.

Best,
Mark A. Hershberger
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Pre-release announcement for MediaWiki releases 1.23.6, 1.22.13 and 1.19.21

[Mark A. Hershberger]

Hello everyone,

This is a notice that on Wednesday, October 28, 2014, between
20:00-22:00 UTC, we will release maintenance updates for current and
supported branches of the MediaWiki software. Downloads and patches will
be available at that time.

Best,
Mark. A. Hershberger
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Re: [Wikisource-l] Standardize ProofreadPage namespaces, again

[Mark A. Hershberger]

wp mirror wpmirror...@gmail.com writes:

 Could someone please file a bug report for Standardization of
 ProofreadPage namespaces.

 I would like to be CC'd on this issue. I have looked at
 https://bugzilla.wikimedia.org/show_bug.cgi?id=43934, but it a bit
 off the mark.

If you want to be CC'd, you'll have to create an account.

https://bugzilla.wikimedia.org/createaccount.cgi

If you create an account, you may as well open the bug that you want
opened yourself. so that you can properly describe what you want.

See http://www.mediawiki.org/wiki/How_to_report_a_bug for more help.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Invitation to this Friday's MediaWiki Cooperation G+ hangout

[Mark A. Hershberger]

Please join us for our fourth online meeting of the MediaWiki
Cooperation at 17 October, 2014 at 3 PM UTC. We'll discuss the current
state of things and talk about the Environmental Scan we're undertaking
and how you can be involved.

More information is available:
https://www.mediawiki.org/wiki/MediaWiki_Cooperation/Meetings/2014-10-17_Telco
https://plus.google.com/events/ce30npoet5jkag8ij64ciro6s5s

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Branching extensions for 1.24

[Mark A. Hershberger]

Antoine Musso hashar+...@free.fr writes:

 Le 05/10/2014 21:06, Bartosz Dziewoński a écrit :
 I note that this is missing release branches for skins entirely, which
 we're also going to need.

 Can you bug fill this please?

 The script that creates the extensions release branch needs to be
 tweaked. It is:

  mediawiki/tools/release.git
  make-extension-branches/make-extension-branches

I've been making some extensive changes to this script to help with the
announcement.  I'll update it to do skins and start submitting my
changes.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Branching extensions for 1.24

[Mark A. Hershberger]

Since it hasn't been done yet, We'll be branching the extensions for
REL1_24 next Friday, Oct 10.

We're announcing this now because we will be publishing a list of
extensions with their proposed branch point later today (Saturday,
Oct 4).  This is to avoid the problems we had last time and to allow
extension developers to select a better branch point if they so desire.

Thanks,

Mark and Markus.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Branching extensions for 1.24

[Mark A. Hershberger]

m...@nichework.com (Mark A. Hershberger) writes:

 We're announcing this now because we will be publishing a list of
 extensions with their proposed branch point later today (Saturday,
 Oct 4).  This is to avoid the problems we had last time and to allow
 extension developers to select a better branch point if they so desire.

The list of extensions and proposed branchpoints is up at
https://www.mediawiki.org/wiki/MediaWiki_1.24/Extension_branchpoints

Thanks,

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Backing out REL1_24

[Mark A. Hershberger]

Legoktm legoktm.wikipe...@gmail.com writes:

 On 9/22/14 1:10 PM, Mark A. Hershberger wrote:
 
 In deference to the concerns raised by James Forrester, Markus and I
 have decided not to back out the REL1_24 branch.

 Will you be creating the REL1_24 branches for extensions and skins, or
 would you like me to do that?

You can do it if you like.  There is a script at
https://git.wikimedia.org/blob/mediawiki%2Ftools%2Frelease/HEAD/make-release%2Fmake-branches
that will help with this.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Backing out REL1_24

[Mark A. Hershberger]

m...@nichework.com (Mark A. Hershberger) writes:

 Legoktm legoktm.wikipe...@gmail.com writes:

 On 9/22/14 1:10 PM, Mark A. Hershberger wrote:
 
 In deference to the concerns raised by James Forrester, Markus and I
 have decided not to back out the REL1_24 branch.

 Will you be creating the REL1_24 branches for extensions and skins, or
 would you like me to do that?

 You can do it if you like.  There is a script at
 https://git.wikimedia.org/blob/mediawiki%2Ftools%2Frelease/HEAD/make-release%2Fmake-branches
 that will help with this.

Note that you'll need to modify this to handled the new skins
repository.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Backing out REL1_24

[Mark A. Hershberger]

In deference to the concerns raised by James Forrester, Markus and I
have decided not to back out the REL1_24 branch.

Less than 80 hours have passed since the branch was made, so there
hasn't been time to make any major technical changes in the code base.
That leaves the social concerns that James raises.  We respect him and
his work as product manager for editing and don't want to make him
suffer as the result of this snafu.

That said, I need to clarify some things about the schedule for
releases.

For about a year now, we've used the schedule:
https://www.mediawiki.org/wiki/WikiReleaseTeam/Release_timeline

Markus did filled in the dates as a result of this
situation, but we had already agreed on a release date, and, as a
result, a branch point.

(Markus and I are not the only people who have edited the
page, so it wasn't unknown.  Still, we could have done a much better job
of publicizing it.  Thankfully, this incident has led to it being
publicized.)

In this vein, we'd like to announce the date of the 1.25 release now and
its respective branch point.

1.25 is scheduled for release on Wednesday, May 27th, 2015. Using the
formula on that page (6 weeks prior to the release date), the branch
date for REL1_25 will be April 15th, 2015 and this will be announced
(again) on April 8th so that everyone will have a week's notice to merge
anything that is necessary for 1.25.

Thanks, and I hope this clarifies any misunderstanding.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Backing out REL1_24

[Mark A . Hershberger]

Dear Wikitech-l 

REL1_24 was branched and announced ahead of schedule[0].

Our schedule[1] clearly states that we will announce a branch one week
before we make one in order to allow developers to put any necessary work
into the branch and keep backports to a minimum.

The current release is planned for 2014-11-26[2].  According to our
schedule, the actual REL1_24 branch should be made on 2014-10-22.

Please excuse the error and do not deprecate anything while we make the
necessary corrections. Unless there is a good reason to keep the branch,
we will revert the current REL1_24 branch on Monday evening.

Finally, while we are very happy to have help with the release work, we
do ask that you coordinate with us to ensure a controlled process free
of disruption.

Signed,

Mark and Markus

[0] 
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:REL1_24,n,z)
[1] 
https://www.mediawiki.org/wiki/WikiReleaseTeam/Release_process#Release_process_start
[2] https://www.mediawiki.org/wiki/WikiReleaseTeam/Release_timeline

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [wiki co-op] Questions to address in tomorrow's user group meeting

[Mark A . Hershberger]

Quim asks a couple of good questions that I think we should discuss in
tomorrow's meeting.

It would be good to clarify whether this group aims to work on anything
related to mediawiki.org.[1]

Why not adding MediaWiki explicitly in the name of the group?[2]

If you missed the announcement of this user group meeting, you can find
all the information you need to join it on MediaWiki.org.[3]

Hope to see you there!

Mark.

[1] 
https://www.mediawiki.org/wiki/Thread:Talk:Groups/Proposals/Wiki_Co-op/Responsibilities_over_mediawiki.org%3F
[2] 
https://www.mediawiki.org/wiki/Thread:Talk:Groups/Proposals/Wiki_Co-op/MediaWiki_Cooperation%3F
[3] https://www.mediawiki.org/wiki/Wiki_Co-op/Meetings/2014-09-05_Telco

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Help in modifying Template:Extension to support user ratings

[Mark A. Hershberger]

Legoktm legoktm.wikipe...@gmail.com writes:

 On 8/18/14, 8:47 AM, Chad wrote:
 On Mon, Aug 18, 2014 at 4:54 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 Has it already been asked anywhere *whether* to make these ratings
 available on mediawiki.org?

Yes.  This is a GSoC project that was accepted.  Getting the ratings to
mw.o is the final step of that.

https://www.mediawiki.org/wiki/User:Adi.iiita/Gsoc2014

As XKCD makes clear, though, ratings like this have problems.  We didn't
ask Aditya to solve all those problems.

Instead, we want to start bootstrapping a way for users of MW extensions
to provide feedback.  If someone solves the problems with ratings, I'd
love to see that implemented on mw.o.

For now, though, this is a step towards improving the ecosystem for MW
users.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Linux distros or Solaris for MediaWiki

[Mark A. Hershberger]

Max Semenik maxsem.w...@gmail.com writes:

 The main issue with packages is not even the version. It is kinda expected
 that distros don't have bleeding-edge packages, and 1.19 will be supported
 for almost a year from now.

This was done with Debian specifically in mind.

 However all packages I know of (Debian flavors and not) split MW
 directory and put its parts into different places, trying to follow
 the Filesystem Hierarchy Standard. The result is [...] outright
 breakages because our code base generally assumes that everything lies
 in one place.

These are bugs that should be fixed.  Release management has worked
closely with Debian and Fedora packagers to improve their packaging
because, despite any on-wiki disclaimers, people will continue to use
apt-get and yum to install MediaWiki.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Adding external libraries to core (SwiftMailer)

[Mark A. Hershberger]

Tony Thomas 01tonytho...@gmail.com writes:

   We were having discussions regarding putting the new
 SwiftMailer[1] lib in/out of core, after the merge of the change
 https://gerrit.wikimedia.org/r/#/c/135290. Tyler recommends to add the
 installer code to the composer.json and not to add the SwiftMailer code to
 the core.

Thank you!  I think the more use we make of composer, the better.

I do have one concern about the tarballs we produce.

It looks like it will be necessary to pre-populate vendor with
composer.json dependencies like this one -- libraries that are essential
-- in order to make sure that a tarball installation require downloading
anything but the tarball itself.

Thoughts?

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki 1.23 release postponed by one week

[Mark A. Hershberger]

Legoktm legoktm.wikipe...@gmail.com writes:
 I admit I haven't been tracking the release progress very much, but it
 would have been nice if there had been an email to wikitech-l a week
 or so ago saying that there's still a blocker that needs
 help/patches/reviews; I (and probably other people) would have been
 willing to help out so we don't end up in the situation we're in right
 now where the patch is trivial but just needed people to look at it.

Thanks for the feedback.  This will help us improve and refine the
release process.

That bug is one of the issues that needs to be fixed, but there are a
couple more that we're looking at:

https://bugzilla.wikimedia.org/63677 -- Update script is failing midway
due to unknown 'user_password_expires' column
https://bugzilla.wikimedia.org/43817 --  Include short descriptions for
extensions bundled in the release
https://bugzilla.wikimedia.org/65765 -- populateRevisionLength.php
displays Content of archive unavailable error when updating ar_len
field with text stored in archive table

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] List of 1.23 blockers updated

[Mark A. Hershberger]

There is a Bugzilla query that you can use to find the current blockers
for this release:
https://bugzilla.wikimedia.org/buglist.cgi?list_id=317367product=MediaWikiresolution=---target_milestone=1.23.0%20release

This reveals an additional issue that hasn't seen much attention
recently:

https://bugzilla.wikimedia.org/61092 -- Install hangs on 'Setting up
database..' with php errors (due to permissions issue)

Thanks,

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 1.23.0: second release candidate ready for download

[Mark A . Hershberger]

The second release candidate for 1.23.0 (1.23.0-rc.1) is now available
for download.

Note that we're making two changes in the release process:

 1. We'll be making this and all future releases on Wednesday instead of
Thursday or Friday.  This will allow people to avoid late Friday
nights.

 2. We're switching to Semantic Versioning (http://semver.org) for the
release candidates and other releases.

The changes since 1.23.0rc0 are as follows:

 * Added pp_sortkey column to page_props table, so pages can be efficiently
   queried and sorted by property value (bug 58032).
 * Introduced $wgPagePropsHaveSortkey as a backwards-compatibility switch,
   for using the old schema of the page_props table, in case the respective
   schema update was not applied.
 * (bug 13250) Restored method for clearing a watchlist in web UI
   so that users with large watchlists don't have to perform
   contortions to clear them.
 * (bug 63269) Email notifications were not correctly handling the
   [[MediaWiki:Helppage]] message being set to a full URL (the default).
   If you customized [[MediaWiki:Enotif body]] (the text of email 
notifications),
   you'll need to edit it locally to include the URL via the new variable
   $HELPPAGE instead of the parser functions fullurl and canonicalurl; otherwise
   you don't have to do anything.
 * $wgProfileToDatabase was removed. Set $wgProfiler to ProfilerSimpleDB
   in StartProfiler.php instead of using this.
 * The fix for bug 14323 was pushed to MediaWiki 1.24 since the
   changes cause problems for Semantic MediaWiki users.
 * The modules intended for use by custom skins were renamed.

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.23.0-rc.1/RELEASE-NOTES-1.23
https://www.mediawiki.org/wiki/Release_notes/1.23

**

Download:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0-rc.1.tar.gz
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0-rc.1.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.0-rc.1.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.0-rc.1.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

Mark A. Hershberger
(Release Management Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Feedback on 1.23 RC 0

[Mark A. Hershberger]

We've gotten some feedback already -- 
https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/212 -- about the 
RC for MediaWiki 1.23 that Markus made last week.  Hopefully we can get this 
issue addressed in time for SMW users.

Are there any other issues that people have run into that we should know about 
before we do attempt to make a final release of 1.23?

If you've tried the RC and not run into any problems, that would be good to 
know, as well.

Thanks,

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Auth_remoteuser -- please review

[Mark A. Hershberger]

For a current project, I have found that Auth_remoteuser can take care 
of a lot of the grunt work, but I felt the need to update it a little.


I have the feeling (wrong?) that this extension is one that is used in a 
lot of places but it hasn't been touched for a couple of years.


Could I get people to test out the modifications I want to contribute back?

   https://gerrit.wikimedia.org/r/127405 -- mostly just formatting
   https://gerrit.wikimedia.org/r/127406 -- refactoring
   https://gerrit.wikimedia.org/r/127407 -- changing invocation

I've made some effort to keep this compatible with the previous version. 
 If you want to try this out as a drop-in replacement for your current 
Auth_remoteuser, you can use 
http://mah.everybody.org/Auth_remoteuser.php.txt -- but please report 
back any problems you have.


Thanks,

Mark.

--
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Why is Cologne Blue still in core?

[Mark A. Hershberger]

On 03/12/2014 11:47 AM, Jon Robson wrote:

Okay to make sure stuff comes out of this thread...

So unless someone does this before me I am going to move CologneBlue out of
core and into SkinCologneBlue extension and Modern out of core into
SkinModern extension.


Would you mind keeping this work in a branch until 1.23 is released in 
May/April?  That way we could announce what is coming in 1.24 and you 
could merge it in right after 1.23 is released.


Thanks,

Mark.

--
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSOC-2014 aspirant

[Mark A. Hershberger]

On 03/02/2014 10:03 AM, Karan Dev wrote:

I was going through idea page and found interest in Catalogue for
MediaWiki extensions. Please someone guide me where to start ?


There is currently someone working on this project.  I'm new to GSOC, so 
I don't know if you can pair up or not.  If you can, would you be 
interested in that?


Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Making it possible to specify MediaWiki compatibility in extensions

[Mark A. Hershberger]

On 03/01/2014 01:24 PM, Rob Lanphier wrote:

Anyone?  Anyone?  Bueller?


Markus and I already made our opinion when he wrote the RFC and I 
indicated my willingness to merge Jeroen's commits.  I was holding off 
for any on-list objections being raised


Unless anyone raises a concrete objection now, I think we should JFDI.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The Zürich Hackathon and you

[Mark A. Hershberger]

On 02/06/2014 07:17 PM, Quim Gil wrote:
 Hi, the registration to the Zürich Hackathon will open very soon.

\o/

I'm looking forward to this as I plan on bringing along some newbies.

 * defining the schedule

How much of the previous years schedules can be reused?

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Monthly point releases

[Mark A. Hershberger]

Subject: Monthly point releases

Based on the issues raised during a meeting we had at the Architecture Summit a 
couple of weeks ago, those of us involved in MediaWiki release management have 
decided to introduce a monthly point-release cycle.  On the last Thursday of 
every month we'll collect fixes that have been made and release them for 
download.

We plan to continue to use the Known Issues subpage[1] to drive the issues 
that are incorporated into the release.  This means that if you have an issue 
that you think should be addressed before the next major release, you can add 
it to the Known Issues page.  We'll review it and, if we agree that it is an 
appropriate issue for a point release, then we'll try to get it resolved.

Of course, this is a community-driven effort, so issues that have working code 
attached are more likely to be resolved in a point release than requests 
without code.  If you cannot provide patches, that doesn't mean that your issue 
won't be fixed.  Instead, you can help us find someone to fix it and further 
help by testing any fixes provided.

We hope that this will mean a more usable MediaWiki.

Thanks,

Mark.

[1] https://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Monthly point releases

[Mark A. Hershberger]

Based on the issues raised during a meeting we had at the Architecture Summit a 
couple of weeks ago, those of us involved in MediaWiki release management have 
decided to introduce a monthly point-release cycle.  On the last Thursday of 
every month we'll collect fixes that have been made and release them for 
download.

We plan to continue to use the Known Issues subpage[1] to drive the issues 
that are incorporated into the release.  This means that if you have an issue 
that you think should be addressed before the next major release, you can add 
it to the Known Issues page.  We'll review it and, if we agree that it is an 
appropriate issue for a point release, then we'll try to get it resolved.

Of course, this is a community-driven effort, so issues that have working code 
attached are more likely to be resolved in a point release than requests 
without code.  If you cannot provide patches, that doesn't mean that your issue 
won't be fixed.  Instead, you can help us find someone to fix it and further 
help by testing any fixes provided.

We hope that this will mean a more usable MediaWiki.

Thanks,

Mark.

[1] https://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Monthly point releases

[Mark A. Hershberger]

Mz writes:
 I received this message twice. Ten-four!

My apologies to you and the list.  I re-sent it because I saw it on mediawiki-l 
but not on wikitech-l.


 Can you please create a 2014 timeline of expected releases? Or at least
 the first half of 2014?

Yes.  I'll do that this week, maybe even tonight.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Known issues in 1.22.0

[Mark A. Hershberger]

There were a few issues whose fixes didn't make it into 1.22.0, but we
should be able to address them within a couple of weeks.  I've been
making a list of the issues that should be fixed in 1.22.1:
https://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues

Please feel free to suggest additions to the list.  You can even make
the additions if you are sure the problem will be rapidly addressed, but
I or another person on the release managment team may revert your edits.

The list currently has the following items:

  * The installer doesn't work for extensions on Windows.
  * There is a problem with Postgres support. bugzilla:46594
https://bugzilla.wikimedia.org/show_bug.cgi?id=46594,
bugzilla:47055
https://bugzilla.wikimedia.org/show_bug.cgi?id=47055,
bugilla:49523

https://www.mediawiki.org/w/index.php?title=Bugilla:49523action=editredlink=1
(User:Saper https://www.mediawiki.org/wiki/User:Saper thinks these
can be fixed by providing FOR UPDATE table support.)
  * Handle explicit plural forms in custom convertPlural in language
classes https://gerrit.wikimedia.org/r/#/c/99088/.
  * Installer reports undefined $nofollow
https://gerrit.wikimedia.org/r/#/c/99654/

Thanks,

Mark.

-- 
http://hexmode.com/

When you are generous, you are not bestowing a gift, but
repaying a debt.
 -- On Living Simply, St John Chrysostom


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we see mw 1.22 today?

[Mark A. Hershberger]

On 11/29/2013 09:43 PM, Sen Slybe wrote:
 It's very excited to upgrade for the new version, so I can final have a try 
 for the visual editor...
 
 Is here not suppose ask this kind question, I sorry if that's so.I just 
 really like mediawikii and WANA thx for you hard work

Please see
https://www.mediawiki.org/wiki/Project:Release_management/Release_timeline
for the current status.

As noted there, the release has been delayed for a week while we address
https://bugzilla.wikimedia.org/56455

Thank you for your interest.  We hope that you'll be able to wait just a
little longer.

Mark.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Applying nofollow only to external links added in revisions that are still unpatrolled

[Mark A. Hershberger]

On 11/17/2013 06:41 AM, Nathan Larson wrote:
 I wanted to see what support
 there might be for applying nofollow only to external links added in
 revisions that are still unpatrolled (bug 42599)

I think I could support this.

After that wiki-spamer site last week, I went looking for various forums
and such where these things are discussed and saw that they
(wiki-spammers) don't seem to see nofollow as a real impediment to their
work.

So, I won't say we should just drop nofollow, but it obviously doesn't
put much in the way of spammers.

Mark.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 1.22.0rc2 ready for download

[Mark A. Hershberger]

We've put together RC2 for 1.22.0.  Please test the tarball and report
any bugs you find on Bugzilla: http://bugzilla.wikimedia.org/

Here are a list of changes made since the last RC. (Links for download
follow this list.)

https://gerrit.wikimedia.org/r/95474
Rename mw.util.wikiGetlink to getUrl -- Catrope

https://gerrit.wikimedia.org/r/95190
mw.util.addPortletLink: Check length before access array index --
Bartosz Dziewoński

https://gerrit.wikimedia.org/r/94951
Include short descriptions for extensions bundled in the release --
MarkAHershberger


https://gerrit.wikimedia.org/r/94945
Change interlanguage link title message key -- Bartosz Dziewoński

https://gerrit.wikimedia.org/r/94942
Do not escape title attribute twice for tooltip-iwiki -- Bartosz Dziewoński

Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.22.0rc2/RELEASE-NOTES-1.22
https://www.mediawiki.org/wiki/Release_notes/1.22

**

Download:
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc2.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.0rc2.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc2.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Applying nofollow only to external links added in revisions that are still unpatrolled

[Mark A. Hershberger]

On 11/17/2013 06:41 AM, Nathan Larson wrote:
 I wanted to see what support
 there might be for applying nofollow only to external links added in
 revisions that are still unpatrolled (bug 42599)

I think I could support this.

After that wiki-spamer site last week, I went looking for various forums
and such where these things are discussed and saw that they
(wiki-spammers) don't seem to see nofollow as a real impediment to their
work.

So, I won't say we should just drop nofollow, but it obviously doesn't
put much in the way of spammers.

Mark.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 1.22.0rc2 ready for download

[Mark A. Hershberger]

On 11/17/2013 04:36 PM, Ryan Kaldari wrote:
 Thanks for the update Mark! In the past, we would announce release
 candidates on MediaWiki-l and also on Mediawiki.org. Are we discontinuing
 those practices?

I apologize for overlooking these other announcements.  I've sent an
email to mediawiki-l and I'll go update MediaWiki.org now.

Mark.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The interwiki table as a whitelist of non-spammy sites

[Mark A. Hershberger]

On 11/14/2013 12:53 PM, Nathan Larson wrote:
 Is there reason to think that a decentralized system would be likely to
 evolve, or that it would be optimal?

Yes.  Wikimedians are motivated to maintain Wikimedia sitess.  I don't
think it is likely that they'll have an interest in maintaining a list
of non-spammy, non-Wikimedia sites.  Using Meta to host the list implies
that there is an interest in the wiki-world outside of Wikimedia.

 It seems to me that most stuff in the
 wikisphere is centered around WMF; e.g. people usually borrow templates,
 the spam blacklist, MediaWiki extensions, and so on, from WMF sites.

Right.  But here you have people re-using the work that the Wikimedia
community has made available -- work they are already doing.  It happens
to work elsewhere, but it is focused on the Wikimedia sites.

 It's just usually more efficient
 to have a centralized repository and widely-applied standards so that
 people aren't duplicating their labor too much.

True, but I don't think centralizing on Meta gives you the efficiency
benefits you want.  You're not re-using work that already happens on
Meta.  Instead, you're asking them to do work that they haven't (yet)
shown an interest in.

And, while MediaWiki extensions are available from MediaWiki.org, a good
number of those extensions have nothing to do with the WMF -- they're
just hosted here.  Several extensions are just hosted on github.  Some
don't even have a reference on MW.o.

This is a problem of community-building, really, and the work of
WikiApiary is good step in that direction.  I have discussed plans for
MW 1.23 (https://bugzilla.wikimedia.org/54425,
https://www.mediawiki.org/wiki/Requests_for_comment/Opt-in_site_registration_during_installation)
for a way to really get this community-building effort going.

Thanks,

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The interwiki table as a whitelist of non-spammy sites

[Mark A. Hershberger]

On 11/13/2013 05:44 AM, Nathan Larson wrote:
 TL;DR: How can we collaboratively put together a list of non-spammy sites
 that wikis may want to add to their interwiki tables for whitelisting
 purposes; and how can we arrange for the list to be efficiently distributed
 and imported?

I like the idea.  Unless I'm mistaken, it seems like most of this idea
could be implemented and improved on as an extension.

While the use of Meta has the advantage of a large number of possible
reviewers, I wonder if it might get better review elsewhere.

Alternatively, we could work with WikiApiary to tag spammy wikis that
his bot finds.

Also, since we're talking about spam and MediaWiki, another good site to
check out would be http://spamwiki.org/mediawiki/.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 1.22.0rc1 ready for download

[Mark A. Hershberger]

We've put together RC1 for 1.22.0.  Please test the tarball and report
any bugs you find on Bugzilla: http://bugzilla.wikimedia.org/

Here are a list of changes made since the last RC. (Links for download
follow this list.)

https://gerrit.wikimedia.org/r/#/c/94393/
Correct tooltip of Next n results on query special pages. -- Alexandre
Emsenhuber

https://gerrit.wikimedia.org/r/#/c/94364/
Fix call to function applyPatch in MysqlUpdater -- umherirrender

https://gerrit.wikimedia.org/r/#/c/93120/
Make it possible to install extensions using Composer -- jeroendedauw

https://gerrit.wikimedia.org/r/#/c/92489/
FormatJson: Remove whitespace from empty arrays and objects -- Kevin Israel

https://gerrit.wikimedia.org/r/#/c/93704/
MWException: Cleanup exception message output -- Brad Jorsch

https://gerrit.wikimedia.org/r/#/c/93703/
redact exception traces and abstract getTrace -- Antoine Musso

https://gerrit.wikimedia.org/r/#/c/92545/
UploadStash::removeFileNoAuth shouldn't need auth -- Brad Jorsch

https://gerrit.wikimedia.org/r/#/c/94119/
MySQL method to find out view + fix fatal in tests -- AlephNull

https://gerrit.wikimedia.org/r/#/c/94261/
wikibits: Add some missing deprecation messages -- Bartosz Dziewoński

https://gerrit.wikimedia.org/r/#/c/94256/
Migrate usage of wikibits in legacy protect.js and upload.js -- Timo Tijhof

https://gerrit.wikimedia.org/r/#/c/93702/
exception: Use MWExceptionHandler::logException in more places -- Timo
Tijhof

https://gerrit.wikimedia.org/r/#/c/93701/
Distinguish redactions from the string REDACTED in formatRedactedTrace
-- Brad Jorsch

https://gerrit.wikimedia.org/r/#/c/93987/
Change mode of non-executable files back to 0644 -- Alexandre Emsenhuber

https://gerrit.wikimedia.org/r/#/c/93971/
Mark Math-specific functions in core as deprecated -- Moritz Schubotz

https://gerrit.wikimedia.org/r/#/c/93412/
Vector: Set media screen on styles.less -- jrobson

https://gerrit.wikimedia.org/r/#/c/92990/
SkinTemplate: Move debug HTML above bottomscripts -- Bartosz Dziewoński

https://gerrit.wikimedia.org/r/#/c/92979/
mediawiki.inspect#dumpTable: fix broken FF workaround -- Ori Livneh

https://gerrit.wikimedia.org/r/#/c/92788/
Wrap up remaining legacy javascript (IEFixes, wikibits) -- Timo Tijhof

https://gerrit.wikimedia.org/r/#/c/92774/
vector: Restore gray search input placeholder -- Bartosz Dziewoński

https://gerrit.wikimedia.org/r/#/c/92770/
Vector: Remove media=screen from skins.vector.beta module -- Timo Tijhof

https://gerrit.wikimedia.org/r/#/c/92557/
Backport information boxes' styles from vforms to shared CSS -- MatmaRex


Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.22.0rc1/RELEASE-NOTES-1.22
https://www.mediawiki.org/wiki/Release_notes/1.22

**

Download:
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc1.tar.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.0rc1.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc1.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Updating the RELEASE-NOTES format for 1.22 and 1.23

[Mark A. Hershberger]

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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Mark A. Hershberger]

On 11/06/2013 11:16 AM, Andre Klapper wrote:
 Bugzilla does not allow centrally reverting all actions by a specific
 person: https://bugzilla.mozilla.org/show_bug.cgi?id=735213

Luckily, though, it does track actions by user.  As a result, I was able
to revert the vandalism.  But it does seem like that (revert all
actions by this user) should be something in Bugzilla itself.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l