[U-Boot] OMAP3 SPL: merge window question
Dear Wolfgang Denk, Sandeep Paulraj and Albert Aribaud,
I'am working on the OMAP3 SPL which is part of my bachelor thesis. Some of the code was already posted - but i staled my work to wait for the new SPL layout and the work on OMAP4 by Aneeshi V.
This weekend Annesh V. released the OMAP4 patch and I now start to merge my OMAP3 patches with the common parts of Aneesh's patch.
I think I can release a patch until the end of the week. Is it possible to get the patch into the upcoming release?
I finish my BA thesis in September - mainlining the code before would be great.
Regards Simon
Le 18/07/2011 10:29, Simon Schwarz a écrit :
Dear Wolfgang Denk, Sandeep Paulraj and Albert Aribaud,
I'am working on the OMAP3 SPL which is part of my bachelor thesis. Some of the code was already posted - but i staled my work to wait for the new SPL layout and the work on OMAP4 by Aneeshi V.
This weekend Annesh V. released the OMAP4 patch and I now start to merge my OMAP3 patches with the common parts of Aneesh's patch.
I think I can release a patch until the end of the week. Is it possible to get the patch into the upcoming release?
You mean you can release a patch before the end of the week, right?
Personally, when a patch was initially submitted before the end of the merge window, I will accept subsequent versions of it and apply them even if they are submitted after the merge window has closed.
Only, be sure to follow *all* rules for submitting new versions of a patch set as laid out in http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions . Particularly:
- *always* provide history for *each* patch
- *always* provide history *below* the commit message delimiter ('---')
- *always* post version N of a patch "in-reply-to" version N-1.
- *never* post a patch set twice under the same version. Even if you forgot some trivial thing like signed-off-by, repost with a *bumped up* version number (and provide updated history)
Be warned that not respecting these rules will result in the patch set being NAKed (and, in turn, will force you to re-post a Vn+1 patch...)
I finish my BA thesis in September - mainlining the code before would be great.
Regards Simon
Amicalement,
Hi Simon, Albert
On 18/07/11 18:47, Albert ARIBAUD wrote:
Le 18/07/2011 10:29, Simon Schwarz a écrit :
Dear Wolfgang Denk, Sandeep Paulraj and Albert Aribaud,
[snip]
Personally, when a patch was initially submitted before the end of the merge window, I will accept subsequent versions of it and apply them even if they are submitted after the merge window has closed.
Provided they are either a simple rebase or an update due to mailing list comments or a correction. After the merge window closes, do not use the existing patches posted inside the merge window to sneak in new features
Only, be sure to follow *all* rules for submitting new versions of a patch set as laid out in http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions . Particularly:
*always* provide history for *each* patch
*always* provide history *below* the commit message delimiter ('---')
*always* post version N of a patch "in-reply-to" version N-1.
*never* post a patch set twice under the same version. Even if you
forgot some trivial thing like signed-off-by, repost with a *bumped up* version number (and provide updated history)
And if the patch is a part of a series, update the version of *all* patches in the series (with a 'no changes' comment for any individual patches in the series which have not been update). Nothing worse than a series being a mix of various versions.
Be warned that not respecting these rules will result in the patch set being NAKed (and, in turn, will force you to re-post a Vn+1 patch...)
Regards,
Graeme
Dear Graeme Russ,
In message 4E23FF5C.7060600@gmail.com you wrote:
And if the patch is a part of a series, update the version of *all* patches in the series (with a 'no changes' comment for any individual patches in the series which have not been update). Nothing worse than a series being a mix of various versions.
Actually I do not want to make this a requirement. If we have a large patch series, and there are changes requested to only one or two of the patches, it is much more efficient to repost just these instead always the whole stack again and again.
Best regards,
Wolfgang Denk
Hi Wolfgang
On Monday, July 18, 2011, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message 4E23FF5C.7060600@gmail.com you wrote:
And if the patch is a part of a series, update the version of *all* patches in the series (with a 'no changes' comment for any individual patches in the series which have not been update). Nothing worse than a series being a mix of various versions.
Actually I do not want to make this a requirement. If we have a large patch series, and there are changes requested to only one or two of the patches, it is much more efficient to repost just these instead always the whole stack again and again.
But this makes a royal mess of the series, especially in patchwork which does not honor in-reply-to: and has been known to not pick up patches. How do we definitively know we have the latest version of *every* patch in the series? It is easy to tell when one has a different version.
And yes it is a pain, but maybe the will help people (me included) to get it right faster and not miss simple things like SoB's, checkpatch et al.
You're not worried about your latest series are you ;)
Regards,
Graeme
Dear Graeme Russ,
In message CALButCJ8f+SW-gbg0KHby2AufcJ30J1JQ-xVXkNzfMTQBXwhwQ@mail.gmail.com you wrote:
Actually I do not want to make this a requirement. =A0If we have a large patch series, and there are changes requested to only one or two of the patches, it is much more efficient to repost just these instead always the whole stack again and again.
But this makes a royal mess of the series, especially in patchwork which does not honor in-reply-to: and has been known to not pick up patches. How do we definitively know we have the latest version of *every* patch in the series? It is easy to tell when one has a different version.
I'm afraid there is no other way than always checking your whoile mail archive. SO far I haven;t found any better method that even halfay reliably does things right automatically.
You're not worried about your latest series are you ;)
No. I repeated the recommendation above a number of times in the past (last time I can remember was when Holger Brunck asked if he has to resind the whole series, and I say this was not needed).
Best regards,
Wolfgang Denk
Hi,
On 07/18/2011 02:29 PM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message CALButCJ8f+SW-gbg0KHby2AufcJ30J1JQ-xVXkNzfMTQBXwhwQ@mail.gmail.com you wrote:
Actually I do not want to make this a requirement. =A0If we have a large patch series, and there are changes requested to only one or two of the patches, it is much more efficient to repost just these instead always the whole stack again and again.
But this makes a royal mess of the series, especially in patchwork which does not honor in-reply-to: and has been known to not pick up patches. How do we definitively know we have the latest version of *every* patch in the series? It is easy to tell when one has a different version.
I'm afraid there is no other way than always checking your whoile mail archive. SO far I haven;t found any better method that even halfay reliably does things right automatically.
You're not worried about your latest series are you ;)
No. I repeated the recommendation above a number of times in the past (last time I can remember was when Holger Brunck asked if he has to resind the whole series, and I say this was not needed).
yes. The thread was: http://lists.denx.de/pipermail/u-boot/2011-July/095452.html
Maybe an update of the wiki page would be helpfull to point this out. Ok there is a hint that the "In-reply-to:" and "References" headers sould be keep correct, but I think an explicitly hint to not repost unchanged patches in a serie and hot to do it with "git send-email" would be helpfull for new users reading this page.
Best regards Holger Brunck
Dear Albert Aribaud,
On 18.07.11, Albert Aribaud wrote:
You mean you can release a patch before the end of the week, right?
Personally, when a patch was initially submitted before the end of the merge window, I will accept subsequent versions of it and apply them even if they are submitted after the merge window has closed.
The problem is that most of my old OMAP3 patch is obsoleted by Aneesh's OMAP4 patch (http://marc.info/?l=u-boot&m=131082102506002&w=2) and the new SPL- Framework (http://marc.info/?l=u-boot&m=131056990001719&w=2).
Therefore most of my old patch will be invalid - and some new parts will be added. It will be a major change not just some corrections.
But I had to wait for these two patches to get finished to add my changes otherwise duplicated and incomaptible work would have been done.
Only, be sure to follow *all* rules for submitting new versions of a patch set as laid out in http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions . Particularly:
*always* provide history for *each* patch
*always* provide history *below* the commit message delimiter ('---')
*always* post version N of a patch "in-reply-to" version N-1.
*never* post a patch set twice under the same version. Even if you
forgot some trivial thing like signed-off-by, repost with a *bumped up* version number (and provide updated history)
Be warned that not respecting these rules will result in the patch set being NAKed (and, in turn, will force you to re-post a Vn+1 patch...)
Understood.
Regards Simon
Hi Simon, Albert
On Monday, July 18, 2011, Simon Schwarz simonschwarzcor@googlemail.com wrote:
Dear Albert Aribaud,
On 18.07.11, Albert Aribaud wrote:
You mean you can release a patch before the end of the week, right?
Personally, when a patch was initially submitted before the end of the merge window, I will accept subsequent versions of it and apply them even if they are submitted after the merge window has closed.
The problem is that most of my old OMAP3 patch is obsoleted by Aneesh's OMAP4 patch (http://marc.info/?l=u-boot&m=131082102506002&w=2) and the new SPL- Framework (http://marc.info/?l=u-boot&m=131056990001719&w=2).
Therefore most of my old patch will be invalid - and some new parts will be added. It will be a major change not just some corrections.
But I had to wait for these two patches to get finished to add my changes otherwise duplicated and incomaptible work would have been done.
Sounds like a good candidate for a 'rule bend' IMHO
Regards,
Graeme
Hi Simon,
Le 18/07/2011 13:31, Simon Schwarz a écrit :
Dear Albert Aribaud,
Just "Albert" is fine. :)
On 18.07.11, Albert Aribaud wrote:
You mean you can release a patch before the end of the week, right?
Personally, when a patch was initially submitted before the end of the merge window, I will accept subsequent versions of it and apply them even if they are submitted after the merge window has closed.
The problem is that most of my old OMAP3 patch is obsoleted by Aneesh's OMAP4 patch (http://marc.info/?l=u-boot&m=131082102506002&w=2) and the new SPL- Framework (http://marc.info/?l=u-boot&m=131056990001719&w=2).
Therefore most of my old patch will be invalid - and some new parts will be added. It will be a major change not just some corrections.
I am not bothered by the fact that after your initial submission, another patch set was submitted that forces you to submit a rebased and adapted patch set version.
What might bother *you*, however, is that ATM the SPL framework patches are RFC, so they won't be applied as such, and Aneesh's OMAP4 patches are not applied yet. And you need those patches applied for yours to be.
But if it *does* happen, I am fine with it. :)
Amicalement,
Dear Albert ARIBAUD,
In message 4E242306.1000007@aribaud.net you wrote:
What might bother *you*, however, is that ATM the SPL framework patches are RFC, so they won't be applied as such, and Aneesh's OMAP4 patches are not applied yet. And you need those patches applied for yours to be. But if it *does* happen, I am fine with it. :)
I hope we see a final version of these patches very soon, and I am willing to pull these into the upcoming release.
Best regards,
Wolfgang Denk
Dear Wolfgang,
On Mon, Jul 18, 2011 at 2:30 PM, Wolfgang Denk wd@denx.de wrote:
Dear Albert ARIBAUD,
In message 4E242306.1000007@aribaud.net you wrote:
What might bother *you*, however, is that ATM the SPL framework patches are RFC, so they won't be applied as such, and Aneesh's OMAP4 patches are not applied yet. And you need those patches applied for yours to be. But if it *does* happen, I am fine with it. :)
I hope we see a final version of these patches very soon, and I am willing to pull these into the upcoming release.
so can I or shall I resend the whole SPL series with the subject changed to "[PATCH v3 N/M]"?
Do you have any comments on patch "[RFC PATCH v2 2/9] spl: add initial support for a generic SPL" where I added the requested documentation?
Best regards, Daniel
Hi Daniel, Wolfgang,
On Monday 18 July 2011 07:49 PM, Daniel Schwierzeck wrote:
Dear Wolfgang,
On Mon, Jul 18, 2011 at 2:30 PM, Wolfgang Denkwd@denx.de wrote:
Dear Albert ARIBAUD,
In message4E242306.1000007@aribaud.net you wrote:
What might bother *you*, however, is that ATM the SPL framework patches are RFC, so they won't be applied as such, and Aneesh's OMAP4 patches are not applied yet. And you need those patches applied for yours to be. But if it *does* happen, I am fine with it. :)
I hope we see a final version of these patches very soon, and I am willing to pull these into the upcoming release.
so can I or shall I resend the whole SPL series with the subject changed to "[PATCH v3 N/M]"?
Do you have any comments on patch "[RFC PATCH v2 2/9] spl: add initial support for a generic SPL" where I added the requested documentation?
Probably one more small change is required in 2/9. CONFIG_SYS_SPL_LDSCRIPT needs to be CONFIG_SPL_LDSCRIPT for the sake of consistency.
br, Aneesh
Hi Aneesh,
On Mon, Jul 18, 2011 at 4:54 PM, Aneesh V aneesh@ti.com wrote:
Probably one more small change is required in 2/9. CONFIG_SYS_SPL_LDSCRIPT needs to be CONFIG_SPL_LDSCRIPT for the sake of consistency.
I'll change it. Documentation is also missing for that option. Thanks for the pointer.
Best regards, Daniel
Dear Daniel,
In message CACUy__W8Znvqx5PKuTi86t0+BDZe3J0K4MafpmTAMeTHTAH0vg@mail.gmail.com you wrote:
Do you have any comments on patch "[RFC PATCH v2 2/9] spl: add initial support for a generic SPL" where I added the requested documentation?
Except for a few tiny details (typos and such) I'm fine with it.
Thanks a lot!
Best regards,
Wolfgang Denk
Dear Simon Schwarz,
In message 20110718082935.GB3867@Zitronenbaum you wrote:
I'am working on the OMAP3 SPL which is part of my bachelor thesis. Some of the code was already posted - but i staled my work to wait for the new SPL layout and the work on OMAP4 by Aneeshi V.
This weekend Annesh V. released the OMAP4 patch and I now start to merge my OMAP3 patches with the common parts of Aneesh's patch.
I think I can release a patch until the end of the week. Is it possible to get the patch into the upcoming release?
I finish my BA thesis in September - mainlining the code before would be great.
I checked in the new SPL code right now.
Best regards,
Wolfgang Denk
participants (7)
-
Albert ARIBAUD -
Aneesh V -
Daniel Schwierzeck -
Graeme Russ -
Holger Brunck -
Simon Schwarz -
Wolfgang Denk