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
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 dirk.be...@googlemail.comwrote:
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 pine.gso.3.96.980526121813.27437n-100...@user2.teleport.com ___ 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
