Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Ingo Molnar]

* Borislav Petkov <borislav.petkov@xxxxxxx> wrote:

> Hi,
> 
> On Thu, May 07, 2009 at 11:18:59PM +0200, Ingo Molnar wrote:
> > 
> > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > > On Thu, 7 May 2009 16:38:07 +0200
> > > Borislav Petkov <borislav.petkov@xxxxxxx> 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.

that's OK! Rebasing of your own commits is fine (especially during 
active development, and especially if there's a lot of outstanding 
review feedback). What matters is to have an eventual cool-down so 
that earlier commits become append-only. That makes a tree more 
trustable - while you never know what's in a fully rebased tree.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/