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@wikimedia.org> wrote:
Option 2 makes the most sense to me:
- Implement new behavior
- Change dependent extensions to use new behavior
- Deprecate old behavior
That said Option 1 seems preferable to 3.
On Wed, Jun 17, 2015 at 10:17 PM, Legoktm legoktm.wikipedia@gmail.com wrote:
On 06/17/2015 09:53 AM, Brad Jorsch (Anomie) wrote:
- 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].
- 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l