<quote name="Ryan Lane" date="2013-02-26" time="14:08:59 -0800">
> If you believe there's a time conflict with this migration let me know and
> I can reschedule it.
Good from my perspective.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Manager A18D 1138 8E47 FAC8 1C7D |
How can we improve the support for databases like PostgreSQL, Oracle,
DB2 and MS SQL?
Getting Jenkins involved in testing isn't the (only) answer, though it
would certainly help.
If developers who were interested in those databases could watch
includes/db, that would help, as well.
If nothing else, I will make an effort to get the developers for those
databases involved in RC testing and make the RC available a month
before release.
--
http://hexmode.com/
There is no path to peace. Peace is the path.
-- Mahatma Gandhi, "Non-Violence in Peace and War"
Chad (or anyone else that might know),
I've a patch [1] that's been hanging out in gerrit for a while, and I was
going to go back and revise it but for some reason I cannot get git review
to download it. It gives a fatal: Couldn't find remote ref
refs/changes/24/44224/10. Manually doing a git ls-remote doesn't show it
either. Other patch sets in the same repo are not affected, I can git
review -d all the ones I tested.
I've made sure my machine is fully up to date (ie: ran git fetch); and I
tried rebasing the patchset via gerrit web to see if that would create the
ref. No such luck :(
Any idea what's going on? Or how to fix it? (is my machine just crazy?)
[1] https://gerrit.wikimedia.org/r/#/c/44224/
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
Hi,
A number of people I know of have ideas and aspirations pertaining to a
DevOps-style deployment process, a.k.a Continuous Deployment. In recent
times a number of pieces of such a system have become functional: Zuul,
Jenkins enhancements for tests, automated acceptance tests, etc.
But looking at mediawiki.org I don't see any sort of central discussion of
overall approach/design/process for DevOps/Continuous Deployment.
Is it time to start such a discussion? Or is this premature?
-Chris
Hi, this is more related to mediawiki rather than wikimedia, but this
list is being watched a bit more I guess.
Is there any extension that allows permanent removal of deleted pages
(or eventually selected deleted pages) from database and removal of
blocked users from database?
Imagine you have a mediawiki wiki that has 20 gb database, where
19.99gb of database is spam and indefinitely blocked users. I think
lot of wikis has this problem, making extension to deal with this
would be useful for many small wikis.
What is exact procedure of properly removing page from database so
that it doesn't break anything? What needs to be deleted and in which
order?
Please propose topics for the Amsterdam Hackathon here:
https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Topics
This is specially useful when there is various people intending to go to
Amsterdam to discuss and work around a specific topic.
For instance, I have heard a couple of people mentioning the possibility
of running a Design workshop. Listing this topic there is useful, as it
will make the organizers and other potential attendees to consider.
Thank you!
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara
<sumanah(a)wikimedia.org> wrote:
> If you merge into mediawiki/core.git, your change is considered safe for
> inclusion in a wmf branch. The wmf branch is just branched out of
> master and then deployed. We don't review it again. Because we're
> deploying more frequently to WMF sites, the code review for merging into
> MediaWiki's core.git needs to be more like deployment/shell-level
> review, and so we gave merge access to people who already had deployment
> access. We have since added some more people. The current list:
> https://gerrit.wikimedia.org/r/#/admin/groups/11,members
Let me elaborate on this. As unclear as our process is for giving
access, it's even less clear what our policy is for taking it away.
If we can settle on a policy for taking access away/suspending access,
it'll make it much easier to loosen up about giving access.
Here's the situation we want to avoid: we give access to someone who
probably shouldn't have it. They continually introduce deployment
blockers into the code, making us need to slow down our frequent
deployment process. Two hour deploy windows become six hour deploy
windows as we need time to fix up breakage introduced during the
window. Even with the group we have, there are times where things
that really shouldn't slip through do. It's manageable now, but
adding more people is going to multiply this problem as we get back
into a situation where poorly conceived changes become core
dependencies.
We haven't had a culture of making a big deal about the case when
someone introduces a breaking change or does something that brings the
db to its knees or introduces a massive security hole or whatever.
That means that if the situation were to arise that we needed to
revoke someones access, we have to wait until it gets egregious and
awful, and even then the person is likely to be shocked that their
rights are being revoked (if we even do it then). To be less
conservative about giving access, we also need to figure out how to be
less conservative about taking it away. We also want to be as
reasonably objective about it. It's always going to be somewhat
subjective, and we don't want to completely eliminate the role of
common sense.
It would also be nice if we didn't have to resort to the nuclear
option to get the point across. One low-stakes way we can use to make
sure people are more careful is to have some sort of rotating "oops"
award. At one former job I had, we had a Ghostbusters Stay Puft doll
named "Buster" that was handed out when someone broke the build that
they had to prominently display in their office. At another job, it
was a pair of Shrek ears that people had to wear when they messed
something up in production. In both cases, it was something you had
to wear until someone else came along. Perhaps we should institute
something similar (maybe as simple as asking people to append "OOPS"
to their IRC nicks when they botch something).
Rob
I believe the OpenID extension is matured to the point where it's usable on
the Wikimedia projects, acting as an OpenID provider. The extension still
needs review and such, but I think it's a good time to discuss how we'd
like to implement this on the projects.
My preference for this would be to have a centralized wiki for identity
urls. The identity urls would be based on user pages. I'm proposing this
for a few reasons:
1. It's easier to deal with identity urls in a centralized location, and it
allows us to avoid including the OpenID extension on every wiki
2. We could very strictly limit our vulnerability surface on this wiki by
only including what's necessary
3. At a later point we could decide to limit all authentication to this
location, pointing login links from all projects/wikis here
4. At a later point we could decide to also use this as a global profile
location
I'd prefer if we avoid the bikeshedding of the domain name in this
discussion, if we are all in agreement over the use of a centralized wiki.
Thoughts?
- Ryan
