On Wed, Jun 24, 2015 at 03:15:03PM +0200, Borislav Petkov wrote:
> In the meantime, I've zapped those two offending patches and am
> testing a v2 pull request.
Ok,
second try. I've zapped the commits which depended on stuff from tip,
ran standard *config builds and did some error injecting with
On Wed, Jun 24, 2015 at 10:50:38AM +0200, Thomas Gleixner wrote:
> One of the solution I use for cross tree dependencies is:
>
> - Apply the commits which create a dependency to a seperate branch
>
> - Let the depending tree pull that branch
>
> - Merge the branch into the proper
On Wed, 24 Jun 2015, Ingo Molnar wrote:
> * Borislav Petkov wrote:
>
> > > If it doesn't work or compile without the tip pile, then I'm not pulling
> > > it at
> > > all, since that means that any problems are not bisectable.
> >
> > Ok, how would you prefer this solved - should I merge the
* Borislav Petkov wrote:
> > If it doesn't work or compile without the tip pile, then I'm not pulling it
> > at
> > all, since that means that any problems are not bisectable.
>
> Ok, how would you prefer this solved - should I merge the relevant tip
> branches
> into it?
So the broken
On Tue, Jun 23, 2015 at 03:49:50PM -0700, Linus Torvalds wrote:
> On Mon, Jun 22, 2015 at 2:11 AM, Borislav Petkov wrote:
> >
> > Important: Please merge this stuff *after* you have merged the tip pile
> > because it depends on it.
>
> What does this mean?
It means that it depends on
On Tue, Jun 23, 2015 at 03:49:50PM -0700, Linus Torvalds wrote:
On Mon, Jun 22, 2015 at 2:11 AM, Borislav Petkov b...@suse.de wrote:
Important: Please merge this stuff *after* you have merged the tip pile
because it depends on it.
What does this mean?
It means that it depends on
On Wed, Jun 24, 2015 at 10:50:38AM +0200, Thomas Gleixner wrote:
One of the solution I use for cross tree dependencies is:
- Apply the commits which create a dependency to a seperate branch
- Let the depending tree pull that branch
- Merge the branch into the proper tip/
* Borislav Petkov b...@suse.de wrote:
If it doesn't work or compile without the tip pile, then I'm not pulling it
at
all, since that means that any problems are not bisectable.
Ok, how would you prefer this solved - should I merge the relevant tip
branches
into it?
So the broken
On Wed, 24 Jun 2015, Ingo Molnar wrote:
* Borislav Petkov b...@suse.de wrote:
If it doesn't work or compile without the tip pile, then I'm not pulling
it at
all, since that means that any problems are not bisectable.
Ok, how would you prefer this solved - should I merge the
On Wed, Jun 24, 2015 at 03:15:03PM +0200, Borislav Petkov wrote:
In the meantime, I've zapped those two offending patches and am
testing a v2 pull request.
Ok,
second try. I've zapped the commits which depended on stuff from tip,
ran standard *config builds and did some error injecting with
On Mon, Jun 22, 2015 at 2:11 AM, Borislav Petkov wrote:
>
> Important: Please merge this stuff *after* you have merged the tip pile
> because it depends on it.
What does this mean?
If it doesn't work or compile without the tip pile, then I'm not
pulling it at all, since that means that any
On Mon, Jun 22, 2015 at 2:11 AM, Borislav Petkov b...@suse.de wrote:
Important: Please merge this stuff *after* you have merged the tip pile
because it depends on it.
What does this mean?
If it doesn't work or compile without the tip pile, then I'm not
pulling it at all, since that means that
Hi Linus,
please pull the EDAC pile for 4.2. A lot of stuff this time.
Important: Please merge this stuff *after* you have merged the tip pile
because it depends on it.
Also, there's a merge conflict with arch/x86/Kconfig but resolving it is
simple. I'm adding an exemplary resolve at the end of
Hi Linus,
please pull the EDAC pile for 4.2. A lot of stuff this time.
Important: Please merge this stuff *after* you have merged the tip pile
because it depends on it.
Also, there's a merge conflict with arch/x86/Kconfig but resolving it is
simple. I'm adding an exemplary resolve at the end of
14 matches
Mail list logo
