[U-Boot] Patch submission process

[U-Boot] Patch submission process

[Vipin KUMAR]

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

[U-Boot] Patch submission process

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
backups: always in season, never out of style.

[U-Boot] Patch submission process

[Vipin KUMAR]

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
> 

[U-Boot] Patch submission process

[Tom]

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
>>
> 

[U-Boot] Patch submission process

[Vipin KUMAR]

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