Dear Jerry Van Baren,
In message <49f5b6af.5060...@ge.com> you wrote:
>
> > Maybe I pout a little more meaning in the words "release candiate".
> > After the end of a merge window, there is usually still a long
> > backlog of patches that has not been merged, and after that there are
> >
Wolfgang Denk wrote:
> Dear David Brownell,
>
> In message <200904250105.41050.davi...@pacbell.net> you wrote:
>> Yes. The issue is needing to guess what's up ... so for
>> example, I seem to observe that "merge window closed" must
>> not be the same as "first RC is out", which isn't how the
>> L
Wolfgang Denk wrote:
> Dear David Brownell,
>
> In message <200904250105.41050.davi...@pacbell.net> you wrote:
>> Yes. The issue is needing to guess what's up ... so for
>> example, I seem to observe that "merge window closed" must
>> not be the same as "first RC is out", which isn't how the
>> L
Dear David Brownell,
In message <200904250105.41050.davi...@pacbell.net> you wrote:
>
> Yes. The issue is needing to guess what's up ... so for
> example, I seem to observe that "merge window closed" must
> not be the same as "first RC is out", which isn't how the
> Linux process works. But that
Dear David Brownell,
In message <200904250003.51845.davi...@pacbell.net> you wrote:
>
> Then I'm curious how that dm9000 EEPROM reading bugfix
> landed in net/next ... or is the point that the merge
> window for 2009.05 is still open, since RC1 hasn't yet
> been tagged?
No. End of merge window an
On Saturday 25 April 2009, Ben Warren wrote:
> > Then I'm curious how that dm9000 EEPROM reading bugfix
> > landed in net/next ... or is the point that the merge
> > window for 2009.05 is still open, since RC1 hasn't yet
> > been tagged?
> >
>
> In this case a pretty good argument could be made th
Hi David,
David Brownell wrote:
> On Friday 24 April 2009, Ben Warren wrote:
>
>> 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).
>>
>
> Then I'm curious how that d
David Brownell wrote:
> On Friday 24 April 2009, Dirk Behme wrote:
>> Btw.: Now that -next exists, I can't find patch linked above in it,
>> though :(
>
> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
>
> shows it ... "respects SKIP_LOWLEVEL_INIT". Make sure
> to lo
On Friday 24 April 2009, Ben Warren wrote:
> 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).
Then I'm curious how that dm9000 EEPROM reading bugfix
landed in net/next ... or
On Friday 24 April 2009, Dirk Behme wrote:
> Btw.: Now that -next exists, I can't find patch linked above in it,
> though :(
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
shows it ... "respects SKIP_LOWLEVEL_INIT". Make sure
to look at the "next" branch there; you c
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme 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 ... t
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 wa
12 matches
Mail list logo
