On Thu, Feb 3, 2011 at 8:46 AM, Ewan Mellor <[email protected]> wrote: >> -----Original Message----- >> From: Jay Pipes [mailto:[email protected]] >> Sent: 03 February 2011 13:40 >> To: Armando Migliaccio >> Cc: Ewan Mellor; Andy Smith; Rick Clark; Søren Hansen; >> [email protected] >> Subject: Re: [Openstack] Network Service for L2/L3 Network >> Infrastructure blueprint >> >> On Thu, Feb 3, 2011 at 4:28 AM, Armando Migliaccio >> <[email protected]> wrote: >> > I second what Ewan said about the coding style in nova.virt.xenapi. I >> was >> > responsible for part of refactoring and I am no longer fond of it >> either. I >> > still think that it was good to break xenapi.py down as we did, but >> with >> > hindsight I would like to revise some of the choices made, and make >> the code >> > a bit more Pythonic. >> >> Nothing wrong with proposing for merging a branch that does >> refactoring. It doesn't need to be tied to a bug or blueprint, but if >> you wait until late in the Cactus cycle, it would have a smaller >> chance of making it into Cactus since the priority is not refactoring >> but instead stability and feature parity. >> >> So, nothing stopping anyone from proposing refactoring branches. :) > > Absolutely not, as long as we're not trying to merge conflicting branches. > That was the problem last time -- I18N and the logging changes in particular > were such pervasive pieces of work that it was hard work merging all the > time. Hopefully we won't see the likes of those again for a little while!
Hehe, understood. I did 6 or 7 merge trunks while dealing with i18n, so I feel you :) But, luckily, we don't look to have any of those super-invasive blueprints on deck for Cactus...but you never know ;) -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
