On 9/25/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 16:47:58 -0600 "Grant Likely" grant.likely@secretlab.ca wrote:
On 9/24/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 23:52:29 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
No, that will not work. You would move Grant's base under his feet.
this goes both ways. True, Grant's work is more intrusive, but that just means that all work that is or can be affected by it be staged in a single common tree. My understanding is you have designated the -testing tree for this particular purpose.
I don't think that's quite true. In the last merge window, -testing got used to stage changes for the merge window with the least possible impact. In that case, it was Jon's CMD_* changes which needed to go in first.
Jon's CMD_* changes were performed in stages, with boards being added in between. Sure, after each phase, things inevitably broke, and they were promptly fixed up again, by him and others. Isn't that how your Kconfig changes are going to work (in phases)?
It makes total sense to stage changes in the custodian trees, but Wolfgang retains the right to decide what order those changes get staged into -testing, and also to request custodians to merge/rebase/retest before pulling their tree.
sure, and I can do that, I just wasn't aware of existing blockage. I would have expected blockage to occur between the time you submit patches to the mailing list and when WD applies them to his tree.
I just want your (and others') /subsequent/ patches to include 837x code, so I, and other custodians btw, don't have to duplicate your work unnecessarily and keep on having to play catch up. But it sounds like you're not going to do it in phases, or, at least the phases are going to be clearly marked with releases 1.3.[123]?
Yes, the phases are going to be on the release marks. I have no intention of getting everything in by 1.3.1.
- Conditional compilation will definitely be ready and I hope will go in. This is the change I'm most concerned about being merged first because of the merge conflicts which will occur in the Makefiles and all the changes are done manually. These changes are *almost* ready. I've got a couple of board ports which are still not compiling correctly that need to be fixed, then I'll post the patch set (in the next day or so)
- Mass macro renames might go in for 1.3.1; but I need to test those changes up the wazo before I post them. Most likely I'll have a script which automates this change, which means it can either go in before or at the end of the merge window.
- I'm not even going to attempt migration to kconfig until 1.3.2 or 1.3.3.
Cheers, g.