On 12/23/2010 08:08 AM, Sandy Walsh wrote: > While I completely understand the rationale for this approach, I'm not a fan. > As you say, it's harder to spot dead code, code may be introduced into trunk > without tests, rollbacks are harder (if not near impossible), reviewers have > to go back and look at other merges to get the big picture, etc. > > Single code drop per blueprint. If you want multiple drops, partition the > blueprint into smaller, more digestible units (as with suspend being split > into suspend + lock or guest-requirements into 3-4 dependent blueprints). > > $0.02 > > -Sandy
I am hesitant to add more administrative burden on developers, by requiring multiple blueprints for a single phased feature. I think as long as the architecture and it's implementation phases are outlined in a single Blueprint/spec that should be fine. > > ________________________________________ > From: [email protected] > [[email protected]] on behalf > of Thierry Carrez [[email protected]] > Sent: Thursday, December 23, 2010 4:15 AM > To: [email protected] > Subject: [Openstack] Merging baby steps or full branches > > Hello everyone, > > There was some discussion yesterday around Josh's > diagnostics-per-instance branch merge proposal [1] and on IRC [2] > afterwards. In summary, Josh uses baby steps branch merge proposals, > landing part of the feature as soon as it is ready. > > [1] > https://code.launchpad.net/~jk0/nova/diagnostics-per-instance/+merge/44394 > > [2] http://eavesdrop.openstack.org/irclogs/%23openstack.2010-12-22.log > (see around 17:43:50) > > On the plus side, this technique allows simpler reviews and reduces the > risks of conflict, so it probably ends up being faster. On the minus > side, it's hard to functionally review or test something that is not > complete, so the load on reviewers is, I think, higher. > > Do we have a position on that ? Is it encouraged, discouraged, or nobody > cares either way ? > > My personal take on it is that we should discourage it, since we face > the risk of releasing half-implemented features (a database schema > without anything using it). Features in development can easily be tested > in specific branches until they are complete enough to integrate trunk > (that's what branches are for, after all). This is with my release > manager hat on, obviously: I'm not in any of the -core teams though, and > would like to hear your thoughts on the matter :) > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at [email protected], and delete the original message. > Your cooperation is appreciated. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
