openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Thu, Dec 23, 2010 at 3:15 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> 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