Kvm-Git-Workflow

New git workflow for kvm.git

The old 'master' branch has been abandoned (still available for reviewing history). The new branch structure will be as follows:

'master': contains patches destined for fixes after the current merge windows; for example, after v3.4 has been released, master contains fixes which will be merged during the 3.4 cycle.

'next': contains patches destined for the next merge window; for example, if v3.4 has just been released, then 'next' will be based on the v3.5-rc1 tag (or thereabouts), and will be accepting patches targeted at the 3.6 merge window (when 3.5 is released).

'queue': holding area for patches which have not been tested yet; may be rebased; usually merged into 'next'

'kvm-updates/3.x': unchanged, patches destined for a stable branch

Since 'next' is based on an -rc1 release, it may lack upstream non-kvm fixes (or features) needed for development. To work around that, an 'auto-next' branch will be provided that is a merge of current upstream and 'next' (this is more or less the equivalent of the old 'master' branch). That branch of course will be rebased often.

How to work with the new layout

If you're a developer, usually developing against 'next' is okay. If 'next' is unstable for you or you need a new upstream API, work against 'auto-next', but let the maintainers know that when posting your patch.

If you're working on a fix for the current cycle, work against upstream or 'master' (they should be equivalent most of the time).

If you're a submaintainer, post git pull requests against 'next' or 'master', according to your merge target.

Please ask Avi or Marcelo with any question or suggestion. It's better to ask a "silly" question than develop against a stale tree accidentally and waste your efforts.