[U-Boot] Patch submission process

[Vipin KUMAR <vipin.kumar@st.com>]

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
>