Bazaar

Decentralized with human gatekeeper workflow doubt

Asked by Mira

Hello!

   I was reading about the possible workflows with Bazaar, and I didn't understand very well the right way to use the "Decentralized with human gatekeeper workflow". In the 6.2 chapter of Bazaar User Guide is explained about "mirror" and "feature" branches. Ok, but what happens when we have a gatekeeper? In the 6.3.1 chapter of User guide is the following explanation:

   "When a developer wants their work merged, they ask the gatekeeper to review their change and MERGE it if acceptable"

My doubt is about the correct manner to do the things working in the "Decentralized with human gatekeeper workflow". What of the two ways below is the correct?

1) First way

  - Developer creates the mirror branch (local copy of trunk)
  - Developer creates a feature branch from local trunk
  - Developer make changes on feature branch
  - Developer does a merge of the feature branch into local copy of trunk (mirror branch)
  - Developer request a code review to gatekeeper
  - Gatekeeper reviews the code (the developer's local trunk with the feature branch "already merged")
  - Gatekeeper does a PULL in the developer's local trunk to the main TRUNK

2) Second way

  - Developer creates a branch (copy of the trunk)
  - (The branch above will not be a "mirror" branch, but a FEATURE branch)
  - Developer make changes on feature branch
  - Developer request a code review to gatekeeper
  - Gatekeeper reviews the feature branch of the developer (the only branch the developer has)
  - Gatekeeper does a MERGE of the developer's local "feature branch" into the TRUNK

What of these 2 approaches is the corret?

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Martin Pool
Solved:
Last query:
Last reply:
Revision history for this message
Best Martin Pool (mbp) said : 		#1

Hi Mira,

These are basically both ok but let me explain a bit more about them

> 1) First way
>
>  - Developer creates the mirror branch (local copy of trunk)
>  - Developer creates a feature branch from local trunk
>  - Developer make changes on feature branch
>  - Developer does a merge of the feature branch into local copy of trunk (mirror branch)
>  - Developer request a code review to gatekeeper
>  - Gatekeeper reviews the code (the developer's local trunk with the feature branch "already merged")
>  - Gatekeeper does a PULL in the developer's local trunk

Just to be clear, the developer shouldn't normally be merging into
their mirror of trunk: the whole point of it is that it precisely
represents what's currently in trunk. They may find it useful to have
a local copy so they can easily refer to the contents of trunk to eg
see what other people have merged.

In this model, the developer would typically, after they finish their feature:

1- bzr pull in their mirror of trunk, to make it up to date
2- merge trunk into their feature branch, and resolve any conflicts,
and possibly test or review the integration
3- commit that
4- ask the gatekeeper to review their changes and if appropriate merge
them into the real trunk
5- the developer can then pull into their trunk mirror to see the
results of the integration of their changes

This puts more of the work onto the individual developer to resolve
any integration problems.

>
> 2) Second way
>
>  - Developer creates a branch (copy of the trunk)
>  - (The branch above will not be a "mirror" branch, but a FEATURE branch)
>  - Developer make changes on feature branch
>  - Developer request a code review to gatekeeper
>  - Gatekeeper reviews the feature branch of the developer (the only branch the developer has)
>  - Gatekeeper does a MERGE in the developer's local "feature branch"

The gatekeeper would be typically merging *from* the developer's
branch into the trunk.

This puts more of the work of doing the integration and resolving any
problems onto the gatekeeper, and keeps things very simple for the
developer. So it might be a particularly good choice when many of the
developers are new to version control.

Hope that helps.

--
Martin <http://launchpad.net/~mbp/>

Revision history for this message
Mira (mira-sni) said : 		#2

Thanks Martin Pool, that solved my question.