[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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/05.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it,
though :(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 ... 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/05.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. I can't say for sure if this is how all branches are
handled, though.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 can start from http://git.denx.de/?p=u-boot/u-boot-arm.git Then page to the bottom, "heads" --> next, then shortlog. They're all there, except the dm9000 eeprom bugfix. - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged? My question on that one is how it ever happened in the first place! My thought was that only four boards in the tree seem to use that driver. The AT91sam9 board (whichever) explicitly disables the EEPROM access, as if maybe it were observed to be broken. Two of the other boards are kind of old, maybe not used much. And ISTR counting the fourth board as the one I was poking at, on which the bugfix was developed. > When the merge window opens again, next goes to master and > the fun starts again. I can't say for sure if this is how all branches are > handled, though. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 look at the "next" branch there; you can start from > > http://git.denx.de/?p=u-boot/u-boot-arm.git > > Then page to the bottom, "heads" --> next, then shortlog. > They're all there, except the dm9000 eeprom bugfix. Sorry for being unclear. Yes, your Davinci patches are there. With 'patch linked above' I meant OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/05.html which Jean-Christophe mentioned to apply against -next: "will be apply on the next". Or did I miss it in http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next again? Please correct me then (and send me some more coffee) ;) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 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 that it's a bug fix and not a feature, so can go in 2009.05. Obviously bugs that break builds get more attention than ones that have been in code for a while and nobody noticed. I'll ask Wolfgang to pick it up directly. As you're noticing, how and when patches are picked up is open to many interpretations. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 that it's a bug fix > and not a feature, so can go in 2009.05. Right. It was one of a handful of bugfixes I've sent; I think only one minor one remains (adjusting columns for "mtdpart" output). > Obviously bugs that break > builds get more attention than ones that have been in code for a while > and nobody noticed. I'll ask Wolfgang to pick it up directly. Saw that; thanks. > As > you're noticing, how and when patches are picked up is open to many > interpretations. 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's the only example I've seen for how the new u-boot cycles should work... - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 and release of -rc1 are completely unrelated. The merge window for 2009.06 (6, not 5!) was closed on Fri Apr 03, 2009, 23:59:59 CET. We're in bug fixing mode. See also: http://www.denx.de/wiki/view/U-Boot/ReleaseCycle 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: w...@denx.de Eeeek! 'eval' on strings should have been named 'evil'.-- Tom Phoenix in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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's the only example I've > seen for how the new u-boot cycles should work... 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 several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a "release candiate". That's why we still have no "rc" in the current release cycle. 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: w...@denx.de "I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." - Dennie van Tassel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 >> Linux process works. But that's the only example I've >> seen for how the new u-boot cycles should work... > > 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 > several rounds of debugging / bug fixing needed. IMO it makes little > sense to call anything in this state a "release candiate". > > That's why we still have no "rc" in the current release cycle. Thanks for this info! This is *exactly* what I meant in the previous mail with "actively keep people informed what is going on by posting status info to the mailing list". Thanks and best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 >> Linux process works. But that's the only example I've >> seen for how the new u-boot cycles should work... > > 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 > several rounds of debugging / bug fixing needed. IMO it makes little > sense to call anything in this state a "release candiate". > > That's why we still have no "rc" in the current release cycle. > > Best regards, > > Wolfgang Denk Make sense on "rc" not really being a release candidate. How about tagging "mc" for "Merge Closed"? gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
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 > > several rounds of debugging / bug fixing needed. IMO it makes little > > sense to call anything in this state a "release candiate". > > > > That's why we still have no "rc" in the current release cycle. ... > Make sense on "rc" not really being a release candidate. How about > tagging "mc" for "Merge Closed"? OK - but we have not reached that state either yet, I think. As mentioned before, I have a problem to relate a deadline thing without any direct impact on the code (as the closing of the merge window) to a git tag which represents a certain state. "Merge Closed" definitely represents such a state, but then we could issue "-rc1" as well (using the same free interpretation as in Linux), and it would not indicate what has been asked for: the closinf of the MW. 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: w...@denx.de ... The prejudices people feel about each other disappear when then get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
