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
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 )
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
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
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
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 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
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
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.
On 06/17/2015 09:53 AM, Brad Jorsch (Anomie) wrote:
>1. Merge the core change over Jenkins's objections, then the Flow change
>can be merged as normal. But overriding Jenkins sucks.
Force-merging in a jenkins/zuul managed repository should be avoided as
much as possible, since it will caus
#1 sounds right, Jenkins serves us, not vice versa. The core change's
commit message should reference the two required extension changes.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jun 17, 2015 at 10:53 AM, Brad Jorsch (Anomie)
wrote:
> We have an (informal?) policy that deprecation warnings shouldn't be raised
> in WMF production. Thus if a core patch is going to add deprecation
> warnings we have to make sure that all extensions deployed on the cluster
> are update
We have an (informal?) policy that deprecation warnings shouldn't be raised
in WMF production. Thus if a core patch is going to add deprecation
warnings we have to make sure that all extensions deployed on the cluster
are updated to not trigger the warning. We can accomplish this by carefully
manag
13 matches
Mail list logo