New git workflow

New git workflow

[Avi Kivity]

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

Re: New git workflow

[Takuya Yoshikawa]

On Thu, 05 Apr 2012 20:02:44 +0300
Avi Kivity <avi@redhat.com> wrote:

> 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:

Please update Documentation/virtual/kvm/review-checklist.txt as well:
	2.  Patches should be against kvm.git master branch.

Thanks,
	Takuya

Re: New git workflow

[Avi Kivity]

On 04/06/2012 03:02 PM, Takuya Yoshikawa wrote:
> On Thu, 05 Apr 2012 20:02:44 +0300
> Avi Kivity <avi@redhat.com> wrote:
>
> > 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:
>
> Please update Documentation/virtual/kvm/review-checklist.txt as well:
> 	2.  Patches should be against kvm.git master branch.
>
>

Yes, but let's wait a while until the workflow stabilizes.

-- 
error compiling committee.c: too many arguments to function

Re: New git workflow

[Avi Kivity]

On 04/05/2012 08:02 PM, Avi Kivity wrote:
> I'll publish the new branches tomorrow, with any luck.

There wasn't any luck, so it's only ready today.  To allow chance for
review, I'm publishing next as next-candidate.

Paul/Alex, please review the powerpc bits.  Specifically:

  system.h is gone, so I moved the prototype of load_up_fpu() to
<asm/switch_to.h> and added a #include (8fae845f4956d).
  E6500 was added in upstream in parallel with the split of kvm
E500/E500MC.  I guessed which part of the #ifdef E6500 was to go into,
but please verify (73196cd364a2, 06aae86799c1b).

Please either post fixup patches atop next-candidate, if needed, or
(preferably) post a new tree of the powerpc update based on
b6d33834bd4e, to replace b6d33834bd4e..966cd0f3bdd.

-- 
error compiling committee.c: too many arguments to function

Re: New git workflow

[Paul Mackerras]

On Sun, Apr 08, 2012 at 02:33:32PM +0300, Avi Kivity wrote:
> On 04/05/2012 08:02 PM, Avi Kivity wrote:
> > I'll publish the new branches tomorrow, with any luck.
> 
> There wasn't any luck, so it's only ready today.  To allow chance for
> review, I'm publishing next as next-candidate.
> 
> Paul/Alex, please review the powerpc bits.  Specifically:
> 
>   system.h is gone, so I moved the prototype of load_up_fpu() to
> <asm/switch_to.h> and added a #include (8fae845f4956d).
>   E6500 was added in upstream in parallel with the split of kvm
> E500/E500MC.  I guessed which part of the #ifdef E6500 was to go into,
> but please verify (73196cd364a2, 06aae86799c1b).

All looks OK as far as I can see, but I have asked Scott Wood to
double-check the e500/e500mc bits.

Paul.

Re: New git workflow

[Scott Wood]

On 04/11/2012 07:23 AM, Paul Mackerras wrote:
> On Sun, Apr 08, 2012 at 02:33:32PM +0300, Avi Kivity wrote:
>> On 04/05/2012 08:02 PM, Avi Kivity wrote:
>>> I'll publish the new branches tomorrow, with any luck.
>>
>> There wasn't any luck, so it's only ready today.  To allow chance for
>> review, I'm publishing next as next-candidate.
>>
>> Paul/Alex, please review the powerpc bits.  Specifically:
>>
>>    system.h is gone, so I moved the prototype of load_up_fpu() to
>> <asm/switch_to.h>  and added a #include (8fae845f4956d).
>>    E6500 was added in upstream in parallel with the split of kvm
>> E500/E500MC.  I guessed which part of the #ifdef E6500 was to go into,
>> but please verify (73196cd364a2, 06aae86799c1b).
>
> All looks OK as far as I can see, but I have asked Scott Wood to
> double-check the e500/e500mc bits.

e6500 should have CPU_FTR_EMB_HV.  Otherwise looks OK.

-Scott