Question about COMMITTERS.md

[Stefan Schulte]

Hi,

I'm currently reading COMMITTERS.md to learn the new commit process
with the new "stable" and "master" branches and need some help:

First I picked a simple pull request
https://github.com/puppetlabs/puppet/pull/1636 that I think should go
in the stable branch (at leasts it's no backward incompatible
feature ;-)). So I fetched Adrian's branch and since it was
originally based on master, rebased it onto stable

git rebase --onto stable master

When I merge the rebased branch into stable everything works as
expected. But when I merge the same branch in master I get

* maint-readme_developer_explain_side_effects_in_tests:
(maint) Add documentation on side effects in tests
(packaging) Update PUPPETVERSION to 3.2.0-rc2

Note that the second commit is not part of the original pull request.
stable seems to receive commits that are not present in master, so
when I do the merge-up-procedure, I'd also merge other commits into
master.

Is this supposed to happen?

-Stefan

[Stefan Schulte]

I'd really like to start reviewing pull request more often, but as I
stated above, the current workflow is not clear to me.

[Jeff McCune]

It is possible that commits in stable that are not in the original pull request are merged up into master. As long as you're using merge commits at each step in the process you should be fine.

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To post to this group, send email to puppe...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Jeff McCune]

Please note you should not merge the same branch into master.  Instead you should merge up all of stable like: git checkout master; git merge --no-ff stable

[Andy Parker]

The way I read COMMITERS.md there shouldn't be a merge from stable to
master anymore, instead there should only be a merge from master to
stable when master becomes the new stable.

"Once merged into stable, merge the same change set into master
without doing a rebase as to preserve the commit identifiers....Upon
release of a new major or minor version all of the changes in the
master branch will be merged into the stable branch."

Jeff, I think you are describing the old procedure. In the New
Regiem(tm), a fix on stable will be merged onto stable and master
separately.

--
Andrew Parker
an...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

Join us at PuppetConf 2013, August 22-23 in San Francisco -
http://bit.ly/pupconf13
Register now and take advantage of the Early Bird discount - save 25%!

[Jeff McCune]

Got it, yeah I have been operating under the assumption the two methods yield equivalent results, and the merge-up variation feels somehow cleaner to me personally, so that's what I've been doing as a matter of preference.

As an FYI, the team has a meeting tomorrow morning so we'll hopefully be on the same page tomorrow afternoon and can talk more on the dev list then.

For the time being I whipped up a pull request that contins the difference in the example process and how the history looks as a result of the difference in the process.  This PR is a request for comments and not necessarily what we're going to merge: https://github.com/puppetlabs/puppet/pull/1645