From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] U-Boot ARM merge strategy
Date: Sat, 25 Apr 2009 19:08:29 +0200 [thread overview]
Message-ID: <20090425170829.GA30476@game.jcrosoft.org> (raw)
In-Reply-To: <49F2B6B9.7040300@googlemail.com>
On 09:07 Sat 25 Apr , Dirk Behme wrote:
> Hi Ben,
>
> Ben Warren wrote:
>> Hi Dirk,
>>
>> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme <dirk.behme@googlemail.com>wrote:
>>
>>> Dear Jean-Christophe,
>>>
>>> David Brownell wrote:
>>> ...
>>>>>> http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>>>>> the Patch series and this has been apply in the u-boot-arm/next
>>>> I see that branch now exists ... thanks! :)
>>> ....
>>>> Could you clarify the current merge cycle for me, by the way?
>>>> I know u-boot has switched to 2009.{01,03,05,...} releases,
>>>> which is a big win from where I sit!, with "rc" tags.
>>>>
>>>> What I'm unclear on is what gets merged for 2009.05 versus
>>>> later. Are these "next" branches for the '05 release (which
>>>> hasn't yet hit rc1)? Or for '07 instead?
>>> Yes, I have the same questions. I already tried to ask similar, but
>>> didn't get an answer.
>>>
>>> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
>>>
>>> Maybe my wording was a little unclear?
>>>
>>> Dirk
>>>
>>> Btw.: Now that -next exists, I can't find patch linked above in it,
>>> though :(
>>>
>>
>> My approach is that once the merge window closes, new patches that are not
>> bug fixes go into 'next', which is for the release after the current one (in
>> this case 07). When the merge window opens again, next goes to master and
>> the fun starts again.
>
> Yes, this is my basic understanding, too.
>
> But there are always these ugly details ;)
>
> - What's about patches that remove dead code, unused macros etc. IMHO
> they can be handled like bug fixes and applied while rc?
>
> - What's about patches that are sent while open merge window or before,
> but need some update cycles and are finalized while rc?
Depends, if the patch is send just before the merge just to have time to
finish it during the fix window NO
If the patch is really risky it will depends on it
Otherwise ok
>
> - What about patches which are sent immediately after merge window
> closed (hours - 1 or 2 days)? I already heard something like 'no problem
> if it comes some hours later, if it is fine then I will still apply it'.
For me when the first version of a is send after the close of the merge and
it's not a bug fix, then it will go to the next MW. The only exception will be
if the patch come from an announce or a thread discussion and/or really improve
U-Boot. Otherwise no exception.
>
For next branch, it will depend if you have big change announce or big patch
series I will create one. Otherwise patch will simply wait until the MW.
For other branch, I'm not really a fan expect if it will help people to work
together an a specific task
Best Regards,
J.
next prev parent reply other threads:[~2009-04-25 17:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-12 22:44 [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips David Brownell
2009-04-17 5:44 ` Jean-Christophe PLAGNIOL-VILLARD
2009-04-17 6:31 ` David Brownell
2009-04-17 7:28 ` Jean-Christophe PLAGNIOL-VILLARD
2009-04-18 21:00 ` David Brownell
2009-04-24 16:24 ` Hugo Villeneuve
2009-04-24 19:33 ` David Brownell
2009-04-24 21:45 ` Jean-Christophe PLAGNIOL-VILLARD
2009-04-24 22:40 ` David Brownell
2009-04-25 5:17 ` [U-Boot] U-Boot ARM merge strategy, was: " Dirk Behme
2009-04-25 6:27 ` Ben Warren
2009-04-25 7:03 ` David Brownell
2009-04-25 7:18 ` Ben Warren
2009-04-25 8:05 ` David Brownell
2009-04-25 10:48 ` Wolfgang Denk
2009-04-25 11:40 ` Dirk Behme
2009-04-25 12:55 ` [U-Boot] U-Boot ARM merge strategy David Brownell
2009-04-25 13:53 ` Wolfgang Denk
2009-04-25 18:53 ` David Brownell
2009-04-26 21:38 ` Wolfgang Denk
2009-04-27 13:44 ` [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips Jerry Van Baren
2009-04-27 14:00 ` Wolfgang Denk
2009-04-25 10:30 ` Wolfgang Denk
2009-04-25 7:07 ` [U-Boot] U-Boot ARM merge strategy Dirk Behme
2009-04-25 7:42 ` Ben Warren
2009-04-25 10:46 ` Wolfgang Denk
2009-04-25 11:35 ` Dirk Behme
2009-04-25 13:44 ` Wolfgang Denk
2009-04-27 15:47 ` Detlev Zundel
2009-04-27 19:42 ` Wolfgang Denk
2009-04-28 8:32 ` Detlev Zundel
2009-04-28 9:07 ` Wolfgang Denk
2009-04-25 16:13 ` Ben Warren
2009-04-26 5:15 ` Dirk Behme
2009-04-25 10:41 ` Wolfgang Denk
2009-04-25 17:08 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2009-04-25 17:30 ` Wolfgang Denk
2009-04-25 18:02 ` Jean-Christophe PLAGNIOL-VILLARD
2009-04-25 18:55 ` David Brownell
2009-04-25 6:57 ` [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips David Brownell
2009-04-25 7:11 ` Dirk Behme
2009-04-24 23:46 ` [U-Boot] [PATCH u-boot git] " Ben Warren
2009-04-25 0:36 ` David Brownell
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=20090425170829.GA30476@game.jcrosoft.org \
--to=plagnioj@jcrosoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox