How does it affect jenkins if something/somebody sets verified to -1
for example? Would it block it from merging?
Any -1/-2 in the verified column blocks submitting a change (even, if
other reviewers add a +1 in verified), so if Barry wouldn't be happy,
you can't merge. A workaround is
Or, maybe, it should be possible for the bot to set the verified flag,
instead of the code review (it's not a code review, so a minus one is
misleading, too).
Freundliche Grüße
Florian Schmidt
-Original-Nachricht-
Betreff: Re: [WikimediaMobile] [Update] Browser
May I suggest that Barry should not +1 patches. It gives a false impression
that the code is alright even though the code may not be covered at all. Can we
have it just -1 when there is a problem, and stay silent otherwise?
On Jun 18, 2015, at 8:55 PM, Jon Robson jdlrob...@gmail.com wrote:
Baha I agree with you, but instead of staying silent just commenting a
BarryBot is happy! Browser tests passed without setting any +1 would be
good to know they run.
I also agree with Florian, if we could set Verified +1 or -1 that could be
interesting. How does it affect jenkins if
On Wednesday, June 24, 2015, Brian Gerstle bgers...@wikimedia.org wrote:
On Wed, Jun 24, 2015 at 2:13 PM, Brion Vibber bvib...@wikimedia.org
javascript:_e(%7B%7D,'cvml','bvib...@wikimedia.org'); wrote:
Congrats on another great release!
I also see you're going to be dropping iOS 6 support
I'm happy to act as a sounding board for the design of the service, but I
don't think we should consider moving to the content service until 5.0 is
out. Until then, try to keep us in mind by building well-factored
reusable components :-).
On Wed, Jun 24, 2015 at 2:06 PM, Corey Floyd
We've been stalled for years on adding media playback to the Wikipedia iOS
app due to the impasse between Wikimedia's insistence on free formats and
Apple's insistence on only supporting patented formats.
I'm trying to route around that impasse by getting Ogg and WebM playback up
and running on
Some of you may have noticed a bot [1] providing reviews for the
Mobilefrontend and Gather extensions.
This is a grass routes experiment [2] to see if we can reduce
regressions by running browser tests against every single commit. It's
very crude, and we're going to have to maintain it but we see
Cross posting to mobile-l.
-- Forwarded message --
From: *Sean Pringle* sprin...@wikimedia.org
Date: Wednesday, June 24, 2015
Subject: [Analytics] analtyics-store eventlogging UNION queries
To: A mailing list for the Analytics Team at WMF and everybody who has an
interest in
Excellent!
--stephen
On Wed, Jun 24, 2015 at 11:50 AM, Bernd Sitzmann be...@wikimedia.org
wrote:
+mobile-l
Hi Android devs,
For non-Android devs who are wondering what the issue is: Android string
resource syntax for parameters is based on Java + printf syntax. So, we end
up with
Thanks again for all the work you put into the docs - really great.
On Mon, Jun 22, 2015 at 2:36 PM, Corey Floyd cfl...@wikimedia.org wrote:
woot!
On Mon, Jun 22, 2015 at 1:17 PM, Bernd Sitzmann be...@wikimedia.org
wrote:
We've got a Phabricator project for the Mobile Content Service at
Congrats on another great release!
I also see you're going to be dropping iOS 6 support for future releases --
that'll allow adding code in Swift, and might mean I can upgrade some of
the networking infrastructure in my upcoming audio/video support patch. :D
-- brion
On Wed, Jun 24, 2015 at
Since this is technical, I would say Brian is the best one to talk to.
@Brian it would be good if you could figure out what is the smallest step
we can take when first moving to the service. Also keep in mind we will
have a requirement to measure and compare the user perceived loading time
so we
I haven't been able to use verified yet - I think this is a permission
that Barry doesn't have.
I'm experimenting with him doing no score reviews right now rather
than +1s for good patches. The -1s are worth being as visible as
possible.
I'm hoping to send an update on the status quo but I've
Hello everyone - our latest and greatest as just gone live in the app
store. You can check it out here:
https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8
This release has further UX refinements, better visibility of article
translations, and several stability improvements (Fixed
+mobile-l
Hi Android devs,
For non-Android devs who are wondering what the issue is: Android string
resource syntax for parameters is based on Java + printf syntax. So, we end
up with parameter placeholders like %s %2$s %.2f . Some translators just
think they can use $1, $2, like with PHP or
If you have any requirements that are missing please let me know.
Who on the iOS side would be the best contact person to occasionally run
things by?
In particular, right now I'm wondering if the html route is something that
iOS devs are comfortable with. Or would you prefer a different route
On Wed, Jun 24, 2015 at 2:13 PM, Brion Vibber bvib...@wikimedia.org wrote:
Congrats on another great release!
I also see you're going to be dropping iOS 6 support for future releases
-- that'll allow adding code in Swift,
Indeed! It's starting already :-)
and might mean I can upgrade
18 matches
Mail list logo
