Messages in this thread | | | Date | Wed, 4 Jan 2006 02:41:13 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 8/11] Time: i386 Conversion - part 4: ACPI PM variable renaming and config change. |
| |
john stultz <johnstul@us.ibm.com> wrote: > > > Anyway, I'll tenatively merge these patches into next -mm so they can get a > > bit of testing. Which causes a problem, because you don't then have a tree > > against which to raise a new patch series. > > I greatly appreciate the inclusion! I'm hoping a bit of time in -mm will > shake out any remaining bugs. > > Although I'm not sure I understand what you mean about me not having a > tree? Do you mean a public git tree? >
Sorry. I meant that once I've merged this series into -mm, you can no longer generate a new patch series against -mm! If I were to leave this patch series out of next -mm, you'd have a clean tree to raise patches against.
> > > So perhaps it would be best if you were to > > > > a) Tell me which patches to fold into which other patches to generate a > > series which compiles at every stage and > > > > b) Send me a new set of changelogs for the resulting patch series. > > I've got a set of chained git trees that store each patch, so its very > easy to re-generate the changelog + patches after I've re-arranged them > as you suggested. > > Would a new patch-set to replace the current patchset be preferred here > or do you just want the above?
Replacement would be best. If you can regenerate the diffs against whatever tree you generated the last batch, that would work.
> Similarly, if we do run into bugs, would you prefer incremental fixup > patches or cumulative replacement patches when a new release of the > patchset is generated?
minimally-sized incremental fixes are preferred, please.
> I'm just getting back from vacation tonight, so I'll send whatever you > prefer sometime tomorrow.
That would be good, thanks.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |