[U-Boot-Users] [RFC] Configuration rework for next merge window
Wolfgang,
When the next u-boot merge window opens, I'd like to merge in the build changes needed to support conditional compile. However, this will be an invasive change on the Makefiles so it requires some planning ahead.
The most invasive change is splitting the COBJS definitions into one line per file which is sure to cause merge conflicts with other boards which I'd like to avoid. I see three possible approaches:
1. Merge the COBJS split into -testing now, and ask custodians to base there changes onto that before the merge window opens 2. Merge the COBJS split at the start of the merge window before any other patches are merged 3. Merge the COBJS split at the end of the merge window and let me deal with the conflicts.
My preference is definitely #1, followed by #2. I think getting it in first will result in higher confidence that the change has not broken anything as each of the custodian trees will be testing against it before they request a pull.
Plus, it's less work for me. :-)
My other changes are far less invasive, but more risky. I'd like to get them into -testing also for the test factor, but merge conflicts shouldn't be much of an issue.
Cheers, g.
On Tue, 11 Sep 2007 11:49:04 -0600 "Grant Likely" grant.likely@secretlab.ca wrote:
- Merge the COBJS split into -testing now, and ask custodians to base
there changes onto that before the merge window opens
I agree with this one (#1).
I'd add that -testing get dropped in favour of a new branch on the mainline tree called 'for-1.3.1' or 'for-1.4.0' (or whatever version number WD deems appropriate (it doesn't matter anyway, it can easily be renamed)). The -testing tree is not in the mainline tree, and therefore further off people's radars, and people's perception of its name usually doesn't match its purpose, e.g. tagging an rc- is more likely to be interpreted as a 'test me now' signal.
And people would more likely to understand that new features go on the for-x.y.z branch - I'd personally be more encouraged to develop some given the presence of such a branch.
It would be smart for custodians to follow suit, and maintain two branches each, applying bugfixes to both, with new features only going into one.
Kim
Dear Grant,
in message fa686aa40709111049r50cd858do6123abeeddba78fa@mail.gmail.com you wrote:
When the next u-boot merge window opens, I'd like to merge in the build changes needed to support conditional compile. However, this will be an invasive change on the Makefiles so it requires some planning ahead.
ACK.
The most invasive change is splitting the COBJS definitions into one line per file which is sure to cause merge conflicts with other boards which I'd like to avoid. I see three possible approaches:
- Merge the COBJS split into -testing now, and ask custodians to base
there changes onto that before the merge window opens 2. Merge the COBJS split at the start of the merge window before any other patches are merged 3. Merge the COBJS split at the end of the merge window and let me deal with the conflicts.
My preference is definitely #1, followed by #2. I think getting it in first will result in higher confidence that the change has not broken anything as each of the custodian trees will be testing against it before they request a pull.
I agree. Suggestion: let's wait for 1.3.0-rc2 (next weekend or so); then I'll update u-boot-testing and we use this as base for your work. I agree that we shoul have this in the tree before the next merge window opens.
Plus, it's less work for me. :-)
One more good reason...
My other changes are far less invasive, but more risky. I'd like to get them into -testing also for the test factor, but merge conflicts shouldn't be much of an issue.
OK. Thanks in advance.
Best regards,
Wolfgang Denk
On 9/11/07, Wolfgang Denk wd@denx.de wrote:
The most invasive change is splitting the COBJS definitions into one line per file which is sure to cause merge conflicts with other boards which I'd like to avoid. I see three possible approaches:
- Merge the COBJS split into -testing now, and ask custodians to base
there changes onto that before the merge window opens 2. Merge the COBJS split at the start of the merge window before any other patches are merged 3. Merge the COBJS split at the end of the merge window and let me deal with the conflicts.
My preference is definitely #1, followed by #2. I think getting it in first will result in higher confidence that the change has not broken anything as each of the custodian trees will be testing against it before they request a pull.
I agree. Suggestion: let's wait for 1.3.0-rc2 (next weekend or so); then I'll update u-boot-testing and we use this as base for your work. I agree that we shoul have this in the tree before the next merge window opens.
Sounds good to me. I'll be ready. :-)
Cheers, g.
Hi Grant,
On Tue, Sep 11, 2007 at 11:49:04AM -0600, Grant Likely wrote:
Wolfgang,
When the next u-boot merge window opens, I'd like to merge in the build changes needed to support conditional compile. However, this will be an invasive change on the Makefiles so it requires some planning ahead.
This issue is already solved in pre-2.0.0
Regards, Sascha
On 9/12/07, Sascha Hauer s.hauer@pengutronix.de wrote:
Hi Grant,
On Tue, Sep 11, 2007 at 11:49:04AM -0600, Grant Likely wrote:
Wolfgang,
When the next u-boot merge window opens, I'd like to merge in the build changes needed to support conditional compile. However, this will be an invasive change on the Makefiles so it requires some planning ahead.
This issue is already solved in pre-2.0.0
That may be so, but most of use live and work in Wolfgang's mainline tree which is where my focus is.
Cheers, g.
On Wed, Sep 12, 2007 at 08:28:53AM -0600, Grant Likely wrote:
That may be so, but most of use live and work in Wolfgang's mainline tree which is where my focus is.
Me too, but there's time to play too, and I would really appreciate if you'd have a look at it someday.
Sascha
participants (4)
-
Grant Likely -
Kim Phillips -
Sascha Hauer -
Wolfgang Denk