Option 2 makes the most sense to me:
1. Implement new behavior
2. Change dependent extensions to use new behavior
3. Deprecate old behavior
That said Option 1 seems preferable to 3.
On Wed, Jun 17, 2015 at 10:17 PM, Legoktm legoktm.wikipe...@gmail.com
wrote:
On 06/17/2015 09:53 AM, Brad
I agree, #2 is a sequence of stable states. If any step goes wrong it
doesn't leave the system as a whole in a bad state.
On Thu, Jun 18, 2015 at 8:05 AM, Joaquin Oltra Hernandez
jhernan...@wikimedia.org wrote:
Option 2 makes the most sense to me:
1. Implement new behavior
2. Change
I also would recommend 2. We had this issue recently with some tweaks
Kaldari made to our main menu.
Given that lightning deploys happen we really should make master stable
always.
If Jenkins is barfing on this there may be other extensions out there which
will also barf. It also makes rolling
On Thu, Jun 18, 2015 at 12:13 PM, Yuri Astrakhan
yastrak...@wikimedia.org wrote:
On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg jay...@gmail.com
wrote:
The API currently emits a warning if a query continuation mode isnt
selected.
I guess on July 1 the API could emit an error, and
Le 18/06/2015 16:18, Brad Jorsch (Anomie) a écrit :
On Thu, Jun 18, 2015 at 9:32 AM, Jon Robson jdlrob...@gmail.com wrote:
Smaller commits generally are better
I'm going to call red herring here. Whether or not smaller commits are
really better, one patch that does
+ if (
On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle bgers...@wikimedia.org
wrote:
1. Current, change the default approach:
1. All clients start receiving warnings as *extra payload data* (how
does this even work for API's w/o a response payload?)
What module in api.php doesn't
Le 17/06/2015 19:49, S Page a écrit :
#1 sounds right, Jenkins serves us, not vice versa. The core change's
commit message should reference the two required extension changes.
Whenever we upgrade Zuul, it will recognize in the commit summary
messages headers like Depends-On: gerrit-change-id
I just noticed that Article::getContent is deprecated now, and the code
says that WikiPage::getContent is now the preferred method. What's the
recommended way to get the current text content of a normal wikitext
article now? Would it be this?
$text =
On Thu, Jun 18, 2015 at 10:57 AM, Antoine Musso hashar+...@free.fr wrote:
Though the second patch should have much more content:
- potentially an announcement (think about MW api.php deprecations)
- migration documentation
- a release note entry
Shouldn't all that be in the *first* patch?
Brad Jorsch (Anomie) wrote:
On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle bgers...@wikimedia.org
wrote:
1. Current, change the default approach:
1. All clients start receiving warnings as *extra payload data*
(how does this even work for API's w/o a response payload?)
What
On Thu, Jun 18, 2015 at 11:33 AM, MZMcBride z...@mzmcbride.com wrote:
Brad Jorsch (Anomie) wrote:
On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle bgers...@wikimedia.org
wrote:
1. Current, change the default approach:
1. All clients start receiving warnings as *extra payload data*
On Wed, Jun 17, 2015 at 10:13 PM, Yuri Astrakhan yastrak...@wikimedia.org
wrote:
On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg jay...@gmail.com
wrote:
The API currently emits a warning if a query continuation mode isnt
selected.
I guess on July 1 the API could emit an error,
On Thu, Jun 18, 2015 at 9:32 AM, Jon Robson jdlrob...@gmail.com wrote:
Smaller commits generally are better
I'm going to call red herring here. Whether or not smaller commits are
really better, one patch that does
+ if ( detectOldInput( $input ) ) {
+ $input = upgradeInput( $input );
+
Hello Brad,
Thank you to have taken the time to elaborate on our IRC conversation
yesterday.
Le 17/06/2015 18:53, Brad Jorsch (Anomie) a écrit :
snip
1. Merge the core change over Jenkins's objections, then the Flow change
can be merged as normal. But overriding Jenkins sucks.
2.
I'm reluctant to interject again, but as a client of the API I feel the
need to speak up. Let's work through an example: Clients A, B, C are
using API 1 when the Server adds API 2:
1. Current, change the default approach:
1. All clients start receiving warnings as *extra payload data*
Le 18/06/2015 15:32, Jon Robson a écrit :
I also would recommend 2. We had this issue recently with some tweaks
Kaldari made to our main menu.
Given that lightning deploys happen we really should make master stable
always.
If Jenkins is barfing on this there may be other extensions out
There is no such a thing like properly break. That's like if someone
was happily sad. Come on
On Thu, Jun 18, 2015 at 4:09 PM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
On Wed, Jun 17, 2015 at 10:13 PM, Yuri Astrakhan yastrak...@wikimedia.org
wrote:
On Wed, Jun 17, 2015 at 7:44 PM,
Yep.
--
-- Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Forwarded message --
From: Yuvi Panda yuvipa...@gmail.com
Date: Thu, Jun 18, 2015 at 4:56 PM
Subject: Ongoing Labs Outage Update
To: labs-annou...@lists.wikimedia.org
Yesterday, the filesystem used by many Labs tools suffered a
catastrophic failure, causing most tools to
I guess it comes down to is this: if we're going to continue supporting old
behavior, they should be accessible via the same old requests. *This
removes the need for existing clients to be updated in the first place*.
If we eventually want to delete the old code keeping the old behavior
separated
Thank you for working on this Yuvi and Labs team!
On Thu, Jun 18, 2015 at 9:00 AM, Yuvi Panda yuvipa...@gmail.com wrote:
-- Forwarded message --
From: Yuvi Panda yuvipa...@gmail.com
Date: Thu, Jun 18, 2015 at 4:56 PM
Subject: Ongoing Labs Outage Update
To:
On Thu, Jun 18, 2015 at 9:26 AM, Brian Gerstle bgers...@wikimedia.org
wrote:
I guess it comes down to is this: if we're going to continue supporting
old behavior, they should be accessible via the same old requests. *This
removes the need for existing clients to be updated in the first
On 6/17/15, Eran Rosenthal eranro...@gmail.com wrote:
Sometimes programmers waste their time for implementing
non-useful/non-important features, but sometimes such features aren't just
not useful, but harmful.[1; you are more than welcome to convince me
otherwise]
Both developers, designers
23 matches
Mail list logo
