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 <
jhernandez(a)wikimedia.org> wrote:
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.wikipedia(a)gmail.com>
wrote:
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 zuul to deadlock and freeze[1].
> 2. Split the core patch into two parts: part 1 does everything
except
add
the wfDeprecated() call, while part 2 adds just the
wfDeprecated() call
> and will be merged immediately after. The make-work here just to
make
Jenkins happy sucks and slightly clutters the commit history.
I would prefer this one.
[1]
https://phabricator.wikimedia.org/T93812
-- Legoktm
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Stephane Bisson
Wikimedia Foundation
1 416 270 3830
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org