On 6/17/15, Eran Rosenthal 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 and project ma
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
wrote:
> On 06/17/2015 09:53 AM, Brad Jorsch (Anomie) wrote:
> >1.
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 de
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 ba
On Wed, Jun 17, 2015 at 10:13 PM, Yuri Astrakhan
wrote:
> On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg
> 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 not return any query
> >
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)
wrote:
> On Wed, Jun 17, 2015 at 10:13 PM, Yuri Astrakhan
> wrote:
>
>> On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg
>> wrote:
>>
>> >
>
On Thu, Jun 18, 2015 at 12:13 PM, Yuri Astrakhan
wrote:
> On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg
> 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 not return any query
>> data.
On Thu, Jun 18, 2015 at 9:32 AM, Jon Robson 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 );
+ // wfDeprecated(
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 = $article->getPage()->getContent()->getNativeData
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
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 :
>1. Merge the core change over Jenkins's objections, then the Flow change
>can be merged as normal. But overriding Jenkins sucks.
>
>2. Spl
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: "
So the mediawi
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
On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle
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 have a response payl
Le 18/06/2015 16:18, Brad Jorsch (Anomie) a écrit :
> On Thu, Jun 18, 2015 at 9:32 AM, Jon Robson 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 )
On Thu, Jun 18, 2015 at 10:57 AM, Antoine Musso 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?
Maybe the seco
Brad Jorsch (Anomie) wrote:
>On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle
>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 a
On Thu, Jun 18, 2015 at 11:33 AM, MZMcBride wrote:
> Brad Jorsch (Anomie) wrote:
> >On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle
> >wrote:
> >>1. Current, "change the default" approach:
> >> 1. All clients start receiving warnings as *extra payload data*
> >> (how does this
-- Forwarded message --
From: Yuvi Panda
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 break. This was noticed
q
Yep.
--
-- Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
On Thu, Jun 18, 2015 at 9:26 AM, Brian Gerstle
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 place*.
> If we eventually
Thank you for working on this Yuvi and Labs team!
On Thu, Jun 18, 2015 at 9:00 AM, Yuvi Panda wrote:
> -- Forwarded message --
> From: Yuvi Panda
> Date: Thu, Jun 18, 2015 at 4:56 PM
> Subject: Ongoing Labs Outage Update
> To: labs-annou...@lists.wikimedia.org
>
>
> Yesterday, t
23 matches
Mail list logo
