headers
Raul Cuza | 23 Jan 2012 06:04
Picon
Gravatar

Proposal: Bcfg2 Branching Model

http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel

I've created a wiki page with a proposed branching model and request
your feedback. The goal of this wiki is to document how branches in
the Bcfg2 code repo will be managed. My hope is that it meets the
following stories:

 * As a user, I want to easily clone Bcfg2 and have confidence that it
will work in my environment.

 * As a developer, I want clear guidelines on how to contribute code
and work with others on features and fixes.

 * As QA or release manager, I want to change the CI server's job
configurations as little as possible.

--
Raul Cuza
Permalink | Reply |
headers
Kamil Kisiel | 23 Jan 2012 06:14
Picon

Re: Proposal: Bcfg2 Branching Model

Sounds good to me. First thing I thought of when I saw this email come
in is "why not use git flow?". Glad to see you arrived at basically
the same conclusion :)

On 2012-01-22, at 21:04, Raul Cuza <raulcuza <at> gmail.com> wrote:

> http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel
>
> I've created a wiki page with a proposed branching model and request
> your feedback. The goal of this wiki is to document how branches in
> the Bcfg2 code repo will be managed. My hope is that it meets the
> following stories:
>
> * As a user, I want to easily clone Bcfg2 and have confidence that it
> will work in my environment.
>
> * As a developer, I want clear guidelines on how to contribute code
> and work with others on features and fixes.
>
> * As QA or release manager, I want to change the CI server's job
> configurations as little as possible.
>
> --
> Raul Cuza
Permalink | Reply |
headers
Chris St. Pierre | 23 Jan 2012 14:14
Picon
Gravatar

Re: Proposal: Bcfg2 Branching Model

Looks good, although I imagine making the main development branch
separate from master could cause some confusion.  I think people
expect a) that "running from Git" gets them fancy new features and the
potential for breakage; and b) to be able to submit pull requests
against master.  However, the value of having the pre-written git flow
tools clearly outweighs this, and since this is a common pattern we
should be able to get around this potential confusion with
documentation.

On Mon, Jan 23, 2012 at 12:14 AM, Kamil Kisiel <kamil.kisiel <at> gmail.com> wrote:
> Sounds good to me. First thing I thought of when I saw this email come
> in is "why not use git flow?". Glad to see you arrived at basically
> the same conclusion :)
>
> On 2012-01-22, at 21:04, Raul Cuza <raulcuza <at> gmail.com> wrote:
>
>> http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel
>>
>> I've created a wiki page with a proposed branching model and request
>> your feedback. The goal of this wiki is to document how branches in
>> the Bcfg2 code repo will be managed. My hope is that it meets the
>> following stories:
>>
>> * As a user, I want to easily clone Bcfg2 and have confidence that it
>> will work in my environment.
>>
>> * As a developer, I want clear guidelines on how to contribute code
>> and work with others on features and fixes.
>>
>> * As QA or release manager, I want to change the CI server's job
(Continue reading)

Permalink | Reply |
headers
Raul Cuza | 23 Jan 2012 15:50
Picon
Gravatar

Re: Proposal: Bcfg2 Branching Model

I deducted we would want a production-ready master from our
discussions on the mailing list and IRC. This is one of the things we
should decide explicitly instead of implicitly and I'm glad you
brought it up.

It is culture that dictates whether Master's HEAD is dirty or
as-clean-as-possible. As Jeff Kreeftmeijer blog post succinctly
states, the production release branch and the development branch can
have whatever name we want and git-flow will support it:
http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ .

One of the advantages of master being dirty (i.e. having incomplete
features and what not) is that anyone can just check out the repo and
start doing development. People responding to git pull requests might
have an easier time. My problem with a dirty master is that the main
people doing working on features are also going to be the ones who
will be using git-flow and have learned the repo layout. New people
coming to Bcfg2 will probably try an already made package or use a
tarball. New people going to the git repo will be looking for the
latest features and expect that HEAD on master will work. A broken
master might turn people away who would otherwise be impressed with
Bcfg2's awesomeness.

Remember, most of the code repository's history was spend using SVN.
Code only got committed to the central repo by one or two people (I'm
looking at you Narayan) who was responsible for quality. With GitHub,
we have the potential to have a lot more people committing code
(plugins, etc. etc). The better we make our model and the sooner we
get automated unittesting in place, the easier it will be for those
who respond to pull requests. How well we respond to pull requests
(Continue reading)

Permalink | Reply |
headers
Chris St. Pierre | 23 Jan 2012 16:01
Picon
Gravatar

Re: Proposal: Bcfg2 Branching Model

I obviously commented without doing insufficient research, but the
initial docs on git-flow seemed to suggest that master had to be
clean.  I'd second Holger's suggestion and have master be dirty if we
can do that.

On Mon, Jan 23, 2012 at 9:50 AM, Raul Cuza <raulcuza <at> gmail.com> wrote:
> I deducted we would want a production-ready master from our
> discussions on the mailing list and IRC. This is one of the things we
> should decide explicitly instead of implicitly and I'm glad you
> brought it up.
>
> It is culture that dictates whether Master's HEAD is dirty or
> as-clean-as-possible. As Jeff Kreeftmeijer blog post succinctly
> states, the production release branch and the development branch can
> have whatever name we want and git-flow will support it:
> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ .
>
> One of the advantages of master being dirty (i.e. having incomplete
> features and what not) is that anyone can just check out the repo and
> start doing development. People responding to git pull requests might
> have an easier time. My problem with a dirty master is that the main
> people doing working on features are also going to be the ones who
> will be using git-flow and have learned the repo layout. New people
> coming to Bcfg2 will probably try an already made package or use a
> tarball. New people going to the git repo will be looking for the
> latest features and expect that HEAD on master will work. A broken
> master might turn people away who would otherwise be impressed with
> Bcfg2's awesomeness.
>
> Remember, most of the code repository's history was spend using SVN.
(Continue reading)

Permalink | Reply |
headers
Raul Cuza | 23 Jan 2012 16:24
Picon
Gravatar

Re: Proposal: Bcfg2 Branching Model

If I understand correctly, your proposal is for one permanent branch,
master, and the release-* and "feature" supporting branches listed in
the wiki?

Hoger: hotfix-* and release-* are the same thing, except that hotfix-*
is for unplanned work and it is branched from master. If we don't have
a separate develop and master branch, then hotfix-* would not be
needed.

An example of unplanned work is "there is a security problem we need
to fix yesterday and get out to production as safely as possible."
With a dirty master, we would do this kind of work by branching from a
known good release-tag, applying the changes and then merging back to
HEAD on master. Not having a clean "production ready" branch means
that we may have difficulty removing unwanted commits from a hotfix.
There are workarounds of course, but since branching is so cheap in
Git, Vincent and others have concluded it is better to keep the clean
branch separate from the develop branch.

Raúl

On Mon, Jan 23, 2012 at 10:01, Chris St. Pierre
<chris.a.st.pierre <at> gmail.com> wrote:
> I obviously commented without doing insufficient research, but the
> initial docs on git-flow seemed to suggest that master had to be
> clean.  I'd second Holger's suggestion and have master be dirty if we
> can do that.
>
(Continue reading)

Permalink | Reply |
headers
Holger Weiß | 23 Jan 2012 16:44
Picon
Picon

Re: Proposal: Bcfg2 Branching Model

* Raul Cuza <raulcuza <at> gmail.com> [2012-01-23 10:24]:
> If I understand correctly, your proposal is for one permanent branch,
> master, and the release-* and "feature" supporting branches listed in
> the wiki?

Dunno about Chris, but my proposal was to use two permanent branches:
"master" (for creating the next major release) and "maint" (for creating
the next minor release), as suggested in the gitworkflows(7) manual:

	http://schacon.github.com/git/gitworkflows.html

> An example of unplanned work is "there is a security problem we need
> to fix yesterday and get out to production as safely as possible."
> With a dirty master, we would do this kind of work by branching from a
> known good release-tag, applying the changes and then merging back to
> HEAD on master.

I'd simply commit the fix on the "maint" branch and then merge it up
into "master" (again, as suggested in the manual).

Holger
Permalink | Reply |
headers
Raul Cuza | 6 Feb 2012 06:21
Picon
Gravatar

Re: Proposal: Bcfg2 Branching Model

I've updated http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel
to reflect your feedback.

I still believe we should adopt git-flow as a tool for managing
merges, tags and publishing. I think this will be justified once I've
written up the steps involved with the most common bcfg2.git
repository maintenance tasks using it.

git-flow does not restrict us to their default workflow, as was
proposed in the wiki's original format. The major difference the tool
'imposes' is that the maint branch in git-workflow(7) is replaced by
the prefix release/* branches. I don't see this as a bad thing. There
will be times, as with v1.2.1, v1.2.2 and v1.3.0, when three or more
release branches will need to be worked on at the same time. In this
case v1.3.0 work would be committed to master and the other two
branches would be release/v1.2.1 and release/v1.2.2.

The production branch comes for 'free' with git-flow and has the
advantage that diffs and log searches can be handled using branch
tools instead of using tags. The difference is not really a big deal
because of how git works, but research and troubleshooting with
branches is a little easier for me to get my head around.

CI, I believe, would do its testing against master and would build
releases against tags or the production branch depending on which is
easiest to automate. I'll know better when I outline the steps in
detail.

To summarize:
(Continue reading)

Permalink | Reply |
headers
Holger Weiß | 23 Jan 2012 14:35
Picon
Picon

Re: Proposal: Bcfg2 Branching Model

* Raul Cuza <raulcuza <at> gmail.com> [2012-01-23 00:04]:
> http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel
> 
> I've created a wiki page with a proposed branching model and request
> your feedback. The goal of this wiki is to document how branches in
> the Bcfg2 code repo will be managed.

Thanks a lot, I think it would be great to have the repository layout
documented.

For my taste, the proposal is a bit too complex, though: do we really
need separate "hotfix-*" branches?  Also, are we really expected to meet
the following goal?

>  * As a user, I want to easily clone Bcfg2 and have confidence that it
> will work in my environment.

As a user, I usually want to install a binary package :-)  Or maybe a
source tarball.  In my book, the repository layout should be convenient
for developers and for users interested in the bleeding edge code.
Therefore, I'd prefer the "master" branch to point to the current
development code rather than to a production release.

Personally, I'd opt for the layout proposed in the gitworkflows(7)
manual page, except that we don't need a "pu" branch, and probably not a
"next" branch, either.  This would leave us with a "master" branch which
tracks the commits that should go into the next major release (1.3) and
a "maint" branch which tracks the commits that should go into the next
minor release (1.2.1), plus optionally branches such as "maint-1.1" in
case we'd like to continue to support the 1.1.x code.  In my view, this
(Continue reading)

Permalink | Reply |
headers
Raul Cuza | 23 Jan 2012 16:10
Picon
Gravatar

Re: Proposal: Bcfg2 Branching Model

2012/1/23 Holger Weiß <holger <at> cis.fu-berlin.de>:
> * Raul Cuza <raulcuza <at> gmail.com> [2012-01-23 00:04]:
>> http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel
>>
>> I've created a wiki page with a proposed branching model and request
>> your feedback. The goal of this wiki is to document how branches in
>> the Bcfg2 code repo will be managed.
<snip snip>
> Personally, I'd opt for the layout proposed in the gitworkflows(7)
> manual page, except that we don't need a "pu" branch, and probably not a
> "next" branch, either.  This would leave us with a "master" branch which
> tracks the commits that should go into the next major release (1.3) and
> a "maint" branch which tracks the commits that should go into the next
> minor release (1.2.1), plus optionally branches such as "maint-1.1" in
> case we'd like to continue to support the 1.1.x code.  In my view, this
> would be less complex, it would fit Bcfg2's development process quite
> well, and it would be a layout also used by many other projects
> (including Git itself), so using it would probably follow the principle
> of least surprise.
>
> Holger

When committing a change, the developer has to answer the question
"where do I put this code?" With the master and develop permanent
branches and short lived supporting branches it becomes easy. If the
answer is "I don't know?" then it goes into develop. If the answer is,
I'm working on getting version 1.3.0 out the door and release-1.3.0
exist, it goes in branch release-1.3.0.

By saying master is for the next major release, and maint-*  are for
(Continue reading)

Permalink | Reply |

Gmane