Seems my previous updates on this may not have made it to this list, so
here's another update:
The wikitech dump was rather large and had a lot of revisions (60k
revisions), even though it has a fairly small number of pages (1,600
pages). The dump was about 6.1GB. The vast majority of these
Hi,
I think that irc feed of recent changes is working great, but there is
still a lot of space for improvement.
As Ryan Lane suggested once, we could probably use system of queues
instead of irc which would be even more advanced. My suggestion is to
create some kind of feed that would be in
Hey,
It sounds like an interesting idea. Actually, AWS (I've been working with
it recently for Extension:AWS) has a similar architecture, where you
establish a push notification service using their Simple Notification
Service and have it send messages to a queue using their Simple Queue
Service.
I believe it would require to create a new daemon (preferably written
in c++) which I am willing to write, that could do similar what the
ircd does right now. And that is delivery of new change to all
connected clients.
There would be preferably set of processes that are working together
on this
We actually have an open RFC on this topic:
https://www.mediawiki.org/wiki/Requests_for_comment/Structured_data_push_notification_support_for_recent_changes
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l
I see that the RFC is considering multiple formats, why not support
all of them? We could make the client request the format they like,
either XML or JSON, that would be a matter of dispatcher how it
produce the output data.
On Fri, Mar 1, 2013 at 2:35 PM, Daniel Friesen
Because we made that mistake with the API, and now we're stuck with a bunch
of deadweight formats that do nothing other than increase maintenance
costs. If your first preference as a client developer is for JSON, it's
really not that hard for you to go get a library to receive it in XML
instead,
The RFC doesn't seem to have gotten much interest (only a burst of edits
from Krinkle in August and then it died). But interesting nonetheless.
The one thing I do know is that if this were to be implemented, it would
probably be pretty complex. It would have to support at least a couple of
The problem is that while XML is widely accepted standard supported on
all platforms and languages, JSON, even if it might be better, is not
so well supported in this moment. For this reason I think it would be
cool to be able to offer multiple outputs.
In the end, as you said, it's not that hard
OK Inserted this to hackaton topics as well...
On Fri, Mar 1, 2013 at 3:02 PM, Tyler Romeo tylerro...@gmail.com wrote:
The RFC doesn't seem to have gotten much interest (only a burst of edits
from Krinkle in August and then it died). But interesting nonetheless.
The one thing I do know is
I have not yet found a good and stable library for JSON parsing in c#,
should you know some let me know :)
However, I disagree with I feel like such a project would take an
insane amount of resources to develop. If we wouldn't make it
insanely complicated, it won't take insane amount of time ;).
I still don't see it as too much complex. Matter of month(s) for
volunteers with limited time.
However I quite don't see what is so complicated on last 2 points.
Given the frequency of updates it's most simple to have the client
(user / bot / service that need to read the feed) open the
0mq? RabbitMQ? Seem to fit the use case pretty well / closely.
--
Yuvi Panda T
http://yuvi.in/blog
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Closely, but seems a bit overcomplicated to me. What I proposed is as
simple as you could just use telnet to retrieve the last changes.
In rabbitMQ for example you need to use 3rd libraries for client so
that you can connect to server and obtain some data... But I don't
have a problem with using
On Fri, Mar 1, 2013 at 12:55 AM, Petr Bena benap...@gmail.com wrote:
Hi,
I think that irc feed of recent changes is working great, but there is
still a lot of space for improvement.
As Ryan Lane suggested once, we could probably use system of queues
instead of irc which would be even more
I don't think a custom daemon would actually be needed.
http://redis.io/topics/pubsub
While I was at flickr, we implemented a pubsub based system to push
notifications of all photo uploads and metadata changes to google using
redis as the backend. The rate of uploads and edits at flickr in 2010
web frontend you say?
if you compare the raw data of irc protocol (1 rc feed message) and
raw data of a http request and response for one page consisting only
of that 1 rc feed message, you will see a huge difference in size and
performance.
Also all kinds of authentication required doesn't seem
Migration is done and morebots is logging again. I still need to re-log
past actions, but I'll do that soon. Let me know if you see any migration
issues.
On Fri, Mar 1, 2013 at 12:08 AM, Ryan Lane rlan...@gmail.com wrote:
Seems my previous updates on this may not have made it to this list, so
On Fri, Mar 1, 2013 at 11:46 AM, Asher Feldman afeld...@wikimedia.orgwrote:
don't think a custom daemon would actually be needed.
http://redis.io/topics/pubsub
While I was at flickr, we implemented a pubsub based system to push
notifications of all photo uploads and metadata changes to
On Friday, March 1, 2013, Petr Bena wrote:
web frontend you say?
if you compare the raw data of irc protocol (1 rc feed message) and
raw data of a http request and response for one page consisting only
of that 1 rc feed message, you will see a huge difference in size and
performance.
I
On Friday, March 1, 2013, Tyler Romeo wrote:
On Fri, Mar 1, 2013 at 11:46 AM, Asher Feldman
afeld...@wikimedia.orgjavascript:;
wrote:
don't think a custom daemon would actually be needed.
http://redis.io/topics/pubsub
While I was at flickr, we implemented a pubsub based system
Hi,
We updated Gerrit this morning to 2.5.2-1506-g278aa9a. This is a
minor update to fix a couple of issues we spotted in the previous
upgrade. Downtime was less than 5 minutes.
As always, please let me know or file a bug if you're having any
problems.
-Chad
On 01/03/13 05:22, Petr Bena wrote:
I believe it would require to create a new daemon (preferably written
in c++) which I am willing to write, that could do similar what the
ircd does right now. And that is delivery of new change to all
connected clients.
When this has been proposed in the
- Original Message -
From: Tyler Romeo tylerro...@gmail.com
I think a very light weight proxy that only passes subscribe
commands to
redis would work. A read only redis slave could be provided but I
don't
think it includes a way to limit what commands clients can run,
On 01/03/13 06:04, Petr Bena wrote:
The problem is that while XML is widely accepted standard supported on
all platforms and languages, JSON, even if it might be better, is not
so well supported in this moment. For this reason I think it would be
cool to be able to offer multiple outputs.
On 03/01/2013 03:55 AM, Petr Bena wrote:
As Ryan Lane suggested once, we could probably use system of queues
instead of irc which would be even more advanced. My suggestion is to
create some kind of feed that would be in machine parseable format,
like XML
Whatever you do, please, don't use
On Thu, Feb 28, 2013 at 8:28 PM, Tyler Romeo tylerro...@gmail.com wrote:
Is there anything else that is holding up enabling wgSecureLogin on WMF
wikis? It'd be spectacular if we could actually enable it and take another
step in the right direction for security. If there's anything on the
Hi,
This is a friendly reminder to everyone about the preferred way to
link to bugs in your commit messages. When you include them as
part of the footer, they are indexed and are thus searchable. For
example:
Fixing some weird bug
More explanation
Blah blah blah.
Bug: 1234
Change-Id:
I actually prefer bug numbers in the header.
When looking at the gerrit dashboard it's useful to see from the
commit message whether it is a bug or enhancement to determine what
code I should review first (bugs always win).
I also tend to write very verbose commit messages so I like to put the
Hello,
This is your weekly preview of higher-risk or general you should be
aware of items for the slew of deployments coming in the near term.
== Next week ==
* Monday March 4: first deploy of -wmf11 to production WMF cluster
** General MediaWiki deploy schedule for reference:
On Fri, Mar 1, 2013 at 2:20 PM, Jon Robson jdlrob...@gmail.com wrote:
I actually prefer bug numbers in the header.
+1, also useful for release notes. Could the footer line be
auto-generated for indexing purposes?
Yay for bikeshed topics ;-)
--
Erik Möller
VP of Engineering and Product
Well, that's true if you're only building release notes by copy+pasting
the first line. If it's scripted, it's trivial to pull the bug # from the footer
as well.
And no, commit messages cannot be auto-generated by Gerrit, as
that changes the sha1.
-Chad
On Fri, Mar 1, 2013 at 2:23 PM, Erik
The
proposalhttp://www.mediawiki.org/wiki/Requests_for_comment/RELEASE-NOTES_botis
for a bot to parse commit message for special commands to add some
text to specific sections of the release-notes file. When bot detects a
master merge, it will pull the latest release-notes, change it, and merge
On Sat, Mar 2, 2013 at 3:16 AM, Chad innocentkil...@gmail.com wrote:
Hi,
This is a friendly reminder to everyone about the preferred way to
link to bugs in your commit messages. When you include them as
part of the footer, they are indexed and are thus searchable. For
example:
Fixing
On Fri, 01 Mar 2013 14:45:14 -0800, Nischay Nahata nischay...@gmail.com
wrote:
On Sat, Mar 2, 2013 at 3:16 AM, Chad innocentkil...@gmail.com wrote:
Hi,
This is a friendly reminder to everyone about the preferred way to
link to bugs in your commit messages. When you include them as
part of
I wrote up some quick documentation on OpenID as a provider. Feel free to
modify it, especially for inaccurately used terminology. It's also likely a
good time to start bikeshed discussions on the urls, as I think it'll end
up taking a while to lock that down.
On Fri, Mar 1, 2013 at 2:59 PM, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
On Fri, 01 Mar 2013 14:45:14 -0800, Nischay Nahata nischay...@gmail.com
wrote:
On Sat, Mar 2, 2013 at 3:16 AM, Chad innocentkil...@gmail.com wrote:
Hi,
This is a friendly reminder to everyone about the
Tools should be coded around people. Not the other way around.
Very nicely said Daniel :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 03/01/2013 01:46 PM, Chad wrote:
Hi,
This is a friendly reminder to everyone about the preferred way to
link to bugs in your commit messages.
As specified at
https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines
Eyes on this page edits (if needed) are welcome.
When you
Daniel Friesen dan...@nadir-seen-fire.com wrote:
This is a friendly reminder to everyone about the preferred way to
link to bugs in your commit messages. When you include them as
part of the footer, they are indexed and are thus searchable. For
example:
Fixing some weird bug
More
Tyler left out a critical piece of information: This new subclass is for
constructing a matrix of checkbox options in a form. You feed it a list
of row labels and a list of column labels and it constructs a table of
checkbox options:
Category 1
Category 2
Category 3
41 matches
Mail list logo
