openstack team mailing list archive

[Rick Clark <rick@xxxxxxxxxxxxx>]

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: openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of Thierry Carrez [thierry@xxxxxxxxxxxxx]
> Sent: Thursday, December 23, 2010 4:15 AM
> To: openstack@xxxxxxxxxxxxxxxxxxx
> 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     : openstack@xxxxxxxxxxxxxxxxxxx
> 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 abuse@xxxxxxxxxxxxx, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: OpenPGP digital signature