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
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 (
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
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?
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.
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
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 cause
#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)
bjor...@wikimedia.org 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
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
13 matches
Mail list logo
