Dear Wolfgang, Tom
Although I have managed to submit my patches in the u-boot mainline in the recent past, I am still a newbie to u-boot community. I have a few doubts regarding the patch submission process followed in u-boot.
I hope the answers would be beneficial not just for me but for everyone I read the whole process on the website but what I understood from there and what is really followed seems to be different.
After reading about the patch submission process, I felt that patches can only be sent when the merging window is open but patches are being continuously sent and reviewed.
Is it correct to assume that a patch can be sent at any time and will only be applied to the mainline code during the merging window
Please let me know.
Thanks in advance
Regards Vipin
Dear Vipin KUMAR,
In message 4BB45F3D.8040804@st.com you wrote:
After reading about the patch submission process, I felt that patches can only be sent when the merging window is open but patches are being continuously sent and reviewed.
Is it correct to assume that a patch can be sent at any time and will only be applied to the mainline code during the merging window
First, please keep in mind that there are different types of patches.
- There are bug fixes that correct problems in the existing code. These can go in moe or less any time. In reality, it depends on how urgent the problem is and how intrusive the bug fix is. Urgent fixes and low-intrusive patches go in more easily - for example, if a bug breaks support for a number of boards it makes no sense to continue with the release process without adding this patch - it is the urgency here that counts. On the other hand, if a patch fixes a spelling error in one of the README files, it is NOT urgent, but may go in quickly anyway, because it is obvious that applying this change has no impact on other parts of the code. Compare a patch that fixxes a bug that gets triggered under certain conditions only, but that requiires heavy vchanges to a lot of files - such a patch will go in early in the release process, but not if we are approaching the scheduled release date.
- There are patches that add new features and/or support for new boards and processors. Such patches get accepted for mainline only when the merge window is open. It makes sense to post such patches before that, to get initial review comments and to have the patches clean and ready for posting when the merge window opens.
Some custodians even accept patches before that, and add these for example to their respective "next" branches. This is mostly a matter of the personal style of working of the respective custodian.
- Then there are patches that are intended as RFC, i. e. that are mainly intended to illustrate an idea and ask for discussion of a specific implementation. Such patches are not intended for inclusion into mainline and thus it makes not much sense to synchronize these with the release schedule.
Hope this helps.
Best regards,
Wolfgang Denk
On 4/1/2010 2:45 PM, Wolfgang Denk wrote:
Dear Vipin KUMAR,
In message 4BB45F3D.8040804@st.com you wrote:
After reading about the patch submission process, I felt that patches can only be sent when the merging window is open but patches are being continuously sent and reviewed.
Is it correct to assume that a patch can be sent at any time and will only be applied to the mainline code during the merging window
First, please keep in mind that there are different types of patches.
There are bug fixes that correct problems in the existing code. These can go in moe or less any time. In reality, it depends on how urgent the problem is and how intrusive the bug fix is. Urgent fixes and low-intrusive patches go in more easily - for example, if a bug breaks support for a number of boards it makes no sense to continue with the release process without adding this patch - it is the urgency here that counts. On the other hand, if a patch fixes a spelling error in one of the README files, it is NOT urgent, but may go in quickly anyway, because it is obvious that applying this change has no impact on other parts of the code. Compare a patch that fixxes a bug that gets triggered under certain conditions only, but that requiires heavy vchanges to a lot of files - such a patch will go in early in the release process, but not if we are approaching the scheduled release date.
There are patches that add new features and/or support for new boards and processors. Such patches get accepted for mainline only when the merge window is open. It makes sense to post such patches before that, to get initial review comments and to have the patches clean and ready for posting when the merge window opens.
Some custodians even accept patches before that, and add these for example to their respective "next" branches. This is mostly a matter of the personal style of working of the respective custodian.
Then there are patches that are intended as RFC, i. e. that are mainly intended to illustrate an idea and ask for discussion of a specific implementation. Such patches are not intended for inclusion into mainline and thus it makes not much sense to synchronize these with the release schedule.
Yes, I understand it well now. Thanks for a elaborate reply
Hope this helps.
Best regards,
Wolfgang Denk
Vipin KUMAR wrote:
On 4/1/2010 2:45 PM, Wolfgang Denk wrote:
Dear Vipin KUMAR,
In message 4BB45F3D.8040804@st.com you wrote:
After reading about the patch submission process, I felt that patches can only be sent when the merging window is open but patches are being continuously sent and reviewed.
Is it correct to assume that a patch can be sent at any time and will only be applied to the mainline code during the merging window
First, please keep in mind that there are different types of patches.
- There are bug fixes that correct problems in the existing code. These can go in moe or less any time. In reality, it depends on how urgent the problem is and how intrusive the bug fix is. Urgent fixes and low-intrusive patches go in more easily - for example, if a bug breaks support for a number of boards it makes no sense to continue with the release process without adding this patch - it is the urgency here that counts. On the other hand, if a patch fixes a spelling error in one of the README files, it is NOT urgent, but may go in quickly anyway, because it is obvious that applying this change has no impact on other parts of the code. Compare a patch that fixxes a bug that gets triggered under certain conditions only, but that requiires heavy vchanges to a lot of files - such a patch will go in early in the release process, but not if we are approaching the scheduled release date.
If the patch is a bug fix that should go in a release, please let me know.
There are patches that add new features and/or support for new boards and processors. Such patches get accepted for mainline only when the merge window is open. It makes sense to post such patches before that, to get initial review comments and to have the patches clean and ready for posting when the merge window opens.
Some custodians even accept patches before that, and add these for example to their respective "next" branches. This is mostly a matter of the personal style of working of the respective custodian.
I will take patches or pull requests at any time. Usually they go to arm/master. Outside of the merge window they go arm/next.
Tom
- Then there are patches that are intended as RFC, i. e. that are mainly intended to illustrate an idea and ask for discussion of a specific implementation. Such patches are not intended for inclusion into mainline and thus it makes not much sense to synchronize these with the release schedule.
Yes, I understand it well now. Thanks for a elaborate reply
Hope this helps.
Best regards,
Wolfgang Denk
Hello Tom,
In message 4BB45F3D.8040804@st.com you wrote:
After reading about the patch submission process, I felt that patches can only be sent when the merging window is open but patches are being continuously sent and reviewed.
Is it correct to assume that a patch can be sent at any time and will only be applied to the mainline code during the merging window
First, please keep in mind that there are different types of patches.
- There are bug fixes that correct problems in the existing code. These can go in moe or less any time. In reality, it depends on how urgent the problem is and how intrusive the bug fix is. Urgent fixes and low-intrusive patches go in more easily - for example, if a bug breaks support for a number of boards it makes no sense to continue with the release process without adding this patch - it is the urgency here that counts. On the other hand, if a patch fixes a spelling error in one of the README files, it is NOT urgent, but may go in quickly anyway, because it is obvious that applying this change has no impact on other parts of the code. Compare a patch that fixxes a bug that gets triggered under certain conditions only, but that requiires heavy vchanges to a lot of files - such a patch will go in early in the release process, but not if we are approaching the scheduled release date.
If the patch is a bug fix that should go in a release, please let me know.
No, it was just for clarification mainly. Thanks for your inputs
There are patches that add new features and/or support for new boards and processors. Such patches get accepted for mainline only when the merge window is open. It makes sense to post such patches before that, to get initial review comments and to have the patches clean and ready for posting when the merge window opens.
Some custodians even accept patches before that, and add these for example to their respective "next" branches. This is mostly a matter of the personal style of working of the respective custodian.
I will take patches or pull requests at any time. Usually they go to arm/master. Outside of the merge window they go arm/next.
OK
Tom
Regards Vipin
participants (3)
-
Tom -
Vipin KUMAR -
Wolfgang Denk