[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090508073239.4d04c0d7@pedra.chehab.org>
Date: Fri, 8 May 2009 07:32:39 -0300
From: Mauro Carvalho Chehab <mchehab@...hat.com>
To: Borislav Petkov <borislav.petkov@....com>
Cc: Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>, greg@...ah.com,
norsk5@...oo.com, tglx@...utronix.de, hpa@...or.com,
aris@...hat.com, edt@....ca, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64
Em Fri, 8 May 2009 12:07:38 +0200
Borislav Petkov <borislav.petkov@....com> escreveu:
> Hi,
>
> On Thu, May 07, 2009 at 11:18:59PM +0200, Ingo Molnar wrote:
> >
> > * Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > > On Thu, 7 May 2009 16:38:07 +0200
> > > Borislav Petkov <borislav.petkov@....com> wrote:
> > >
> > > > Hi,
> > > >
> > > > On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> > > > > Regarding workflow, the arch/x86 bits look good to me now, so you've
> > > > > got my Acked-by for that.
> > > >
> > > > Cool, thanks.
> > > >
> > > > Does that mean you're going to pick that one or...
> > > >
> > > > > Most of the EDAC patches are hosted in
> > > > > -mm, so we could carry them in the x86 tree separately as well and
> > > > > export it to linux-next so that -mm will have it automatically.
> > > >
> > > > is the bunch going through Andrew as a whole?
> > > >
> > >
> > > I could. But there's negligible overlap with other EDAC work so
> > > we might as well merge this via IngoTrees or directly from your
> > > tree.
> >
> > If Doug and you agrees too then i have no problem (at all) with
> > Borislav carrying these bits in a separate tree, as long as he also
> > opens an edac-next branch for linux-next and asks Stephen to pull
> > it, and keeps it an append-mostly tree that isnt rebased.
>
> I'll still need to rebase stuff to latest Linus tree for now since we're
> not yet ready reorganizing/cleaning up the code. After it gets merged,
> I'll switch to append-only mode.
One good idea is to split the Kbuild changes into a separate changeset. This
way, if compilation happens to break due to a merge conflict with other patches,
you can just write a fix patch fixing it before the Kbuild one, without
breaking git bisect.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists