From: Avi Kivity <avi@redhat.com>
To: KVM list <kvm@vger.kernel.org>, kvm-ppc <kvm-ppc@vger.kernel.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Alexander Graf <agraf@suse.de>, Paul Mackerras <paulus@samba.org>,
Carsten Otte <carsteno@de.ibm.com>,
"Roedel, Joerg" <Joerg.Roedel@amd.com>
Subject: New git workflow
Date: Thu, 05 Apr 2012 20:02:44 +0300 [thread overview]
Message-ID: <4F7DD034.5090102@redhat.com> (raw)
In a recent conversation, Linus persuaded me that it's time for change
in our git workflow; the following will bring it in line with the
current practices of most trees.
The current 'master' branch will be 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 ping Marcelo or myself with any question or suggestion. It's
better to ask a "silly" question than develop against a stale tree
accidentally and waste your efforts.
I'll publish the new branches tomorrow, with any luck.
--
error compiling committee.c: too many arguments to function
next reply other threads:[~2012-04-05 17:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-05 17:02 Avi Kivity [this message]
2012-04-06 12:02 ` New git workflow Takuya Yoshikawa
2012-04-11 9:42 ` Avi Kivity
2012-04-08 11:33 ` Avi Kivity
2012-04-11 12:23 ` Paul Mackerras
2012-04-11 19:50 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F7DD034.5090102@redhat.com \
--to=avi@redhat.com \
--cc=Joerg.Roedel@amd.com \
--cc=agraf@suse.de \
--cc=carsteno@de.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox