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 < [email protected]> 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 <[email protected]> > 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 > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Stephane Bisson Wikimedia Foundation 1 416 270 3830 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
