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 back a lot easier if things do go wrong. It takes a bit more time to do and seems silly but really is the right way to do this sort of thing. Smaller commits generally are better and I wish we broke down a lot of our patch sets more (due to code review being slow I think sometimes we tend to bundle too many things into any given patch). On 18 Jun 2015 5:36 am, "Stephane Bisson" <sbis...@wikimedia.org> wrote: > 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 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 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@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 > > > > > > -- > Stephane Bisson > Wikimedia Foundation > 1 416 270 3830 > _______________________________________________ > 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
