linux-pm tree changes

Hi,

I'd like you to know some workflow changes regarding the linux-pm tree.

Since it's now possible to create signed tags for Linus to pull from, I won't need the 'pm-for-linus' branch any more and it's gone.  The 'pm-fixes' branch is gone too and replaced by the 'fixes' branch (which currently contains the same material as master).

The idea is that the main development is going to happen in the 'master' branch, which is not going to be rebased and the Linus' tree will be merged into it from time to time (most of the time when the 'master' branch can be fast-forwarded to it).  The 'fixes' branch will be used for pushing urgent

stuff that must go in before the new material in the 'master' branch.

The linux-next branch is going to be based on top of the master branch with the 'fixes' branch merged into it and will contain additional new material that hasn't been added to the master branch yet.  Every patch going through linux-pm has to spend some time in the linux-next branch alone before it is added to the master (or 'fixes') branch (some super-urgent fixes may go directly to the 'fixes' branch, though).

Topic branches are all gone now and they will be re-created as needed.

If you have any questions, please ask.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 9 lines · Rafael J. Wysocki

Hi,

I'd like you to know some workflow changes regarding the linux-pm tree.

Since it's now possible to create signed tags for Linus to pull from, I won't need the 'pm-for-linus' branch any more and it's gone. The 'pm-fixes' branch is gone too and replaced by the 'fixes' branch (which currently contains the same material as master).

Quoted 4 lines

The idea is that the main development is going to happen in the 'master' branch, which is not going to be rebased and the Linus' tree will be merged into it from time to time (most of the time when the 'master' branch can be fast-forwarded to it). The 'fixes' branch will be used for pushing urgent

Not sure what you have in mind for "from time to time",

but random merges
without a clear reason (i.e. "merge Linus to get access to new files X Y Z") are probably going to get you in hot water.

Also, once you stack on your 1st PM commit onto your master, none of your future merges of Linus' tree will be fast forward.

Here is an
example, where I simulate a local change, followed by "time to time" merges of Linus tree. Note each creates a merge, not just the 1st one.

-----------------------------
linux-head$git checkout -b crap v3.1
Checking out files: 100% (17551/17551), done.
Switched to a new branch 'crap'
linux-head$echo foo > foo ; git add foo ; git commit -m '1st pm commit' [crap 1675da3] 1st pm commit

 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 foo

linux-head$git merge v3.2-rc1 2>&1 |grep 'Merge\|Fast' Merge made by recursive.
linux-head$git merge v3.2-rc2 2>&1 |grep 'Merge\|Fast' Merge made by recursive.
linux-head$git merge v3.2-rc3 2>&1 |grep 'Merge\|Fast' Merge made by recursive.
linux-head$git show -m |head -n5
commit 3cbd041875960361ffde72612afadc6c68e94654 (from 6f6028bdbbc63dc71b408da8976f154a2e6a70ee)
Merge: 6f6028b caca6a0
Author: Paul Gortmaker <[email protected]>
Date: Wed Jan 25 13:45:55 2012 -0500
linux-head$
----------------

Having lots of these kinds of pointless merge commits are what will most likely get you in hot water when you ask for it to be pulled.

Maybe I'm just misinterpreting what your plan is.