All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vipin KUMAR <vipin.kumar@st.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Patch submission process
Date: Mon, 05 Apr 2010 09:29:24 +0530	[thread overview]
Message-ID: <4BB9601C.2070904@st.com> (raw)
In-Reply-To: <4BB8BB93.5040006@windriver.com>

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

      reply	other threads:[~2010-04-05  3:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-01  8:54 [U-Boot] Patch submission process Vipin KUMAR
2010-04-01  9:15 ` Wolfgang Denk
2010-04-01 11:38   ` Vipin KUMAR
2010-04-04 16:17     ` Tom
2010-04-05  3:59       ` Vipin KUMAR [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BB9601C.2070904@st.com \
    --to=vipin.kumar@st.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.