On Thu, Dec 23, 2010 at 3:15 AM, Thierry Carrez <[email protected]> wrote: > 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 :)
It's always possible to have a branch pushed to launchpad for the "supertask" and then do merge proposals of smaller subtasks/blueprints into that supertask branch. Then, when the little tasks are done and reviewed, the final merge proposal into trunk contains all the code for the entire major blueprint/task at once while having the benefit of being reviewed in chunks by the team(s) working on it. -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
