Re: [U-Boot] U-Boot ARM merge strategy
Hi Wolfgang, And if we want to make it perfect, each -rc could get a similar announcement, too. Would ne not just add a lot of noise to the ML, without any real new information? If you want detailed information about each action, please feel free and register a RSS feed on the git repository. I think you mean the RSS feeds of the TWiki, right? No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in. Ok, then I simply fail to understand you, as we all agreed that the state of the project is not to be found in the source repository but on a TWiki web page. However, let's move on. Cheers Detlev -- I haven't lost my mind, I know exactly where I left it. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ 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
Dear Detlev, In message m2iqkpp49c@ohwell.denx.de you wrote: And if we want to make it perfect, each -rc could get a similar announcement, too. ^^^ No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in. Ok, then I simply fail to understand you, as we all agreed that the state of the project is not to be found in the source repository but on a TWiki web page. The OP's question was about notification of a rc commit in the git repository. This is something you can find out through the git repo's RSS. 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 ATTENTION: Despite Any Other Listing of Product Contents Found Here- on, the Consumer is Advised That, in Actuality, This Product Consists Of 99.99% Empty Space. ___ 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
Re: [U-Boot] U-Boot ARM merge strategy
Dear Detlev, In message m2hc0aqetd@ohwell.denx.de you wrote: And if we want to make it perfect, each -rc could get a similar announcement, too. Would ne not just add a lot of noise to the ML, without any real new information? If you want detailed information about each action, please feel free and register a RSS feed on the git repository. I think you mean the RSS feeds of the TWiki, right? No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in. 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 In any group of employed individuals the only naturally early riser is _always_ the office manager, who will _always_ leave reproachful little notes ... on the desks of their subordinates. - Terry Pratchett, _Lords and Ladies_ ___ 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
Dear David, In message 200904251153.51380.davi...@pacbell.net you wrote: Just type u-boot merge window at google and click on the very first link. Several other key infrastructure projects make it easy to find that info even without using a search engine. Come on and be reasonable. Yes, the current release state is not on the front page. But it is just one click away. And my reference to google was just because of the argument difficult to find. As a developer, I'd be more likely to look at the GIT summary for status of the GIT tree; its normally the first place to look for such things. I agree fully with this statement. But at the same time I have to point out that this is exactly where our opinions differ: - You expect that the U-Boot git repository mirrors the current state in the release process, ideally in the same way as Linux handles this. - For me, the current phase of the release process is not necessarily reflected by a specific tag on the git tree. This is a (as I think unavoidable) consequence of the existing differences in the prcedures: * In Linux, top-level maintainers will collect patches in their trees and send pull requests to Linus as soon as the merge window opens. So far, most U-Boot custodians do not work like that; they send pull requests only at (or even after) the end of the merge window. * In Linux, the closing of the merge window is maked by the release of the next =-rc1 In U-Boot, -rc1 will only be released after all (or at least most of the) patches that were submitted during the merge window have been applied. Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former. And Linux has had years to develop -- and motivate! -- its merge procedures ... it's a different team and process. Processes need constant tweaking though. And your process page strongly suggests you're using the Linux processes. Hence surprise and confusion when you aren't quite doing so, from folk who use those processes daily. Well, it's exactly my intention to do things differnetly or to cause confusion :-( But the thing is, that we (the custodians and me) are not working (yet?) as the Linux maintainers do. I hope we can improve. I am really thankful for this discussion - IIRC this is the first time ever that suchtopics have been discussed here. Easily addressed though ... that web page can point out some differences. Make a few small things *obviously* different, and people will assume that other things may also differ. I tried to make things a bit clearer. Please have a look at http://www.denx.de/wiki/U-Boot/ReleaseCycle and http://www.denx.de/wiki/U-Boot/DevelopmentProcess and let me know what's unclear or missing or needs improvement (or, even better, edit it yourself -it's a wiki after all, where everybody can contribute). When the RC label just means we only integrate bugfixes now, that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know. Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included. I couldn't stop you, of course. All I'm doing is pointing out what others have also pointed out: that the current process is a bit opaque about some key points. And I'm trying to help with some small suggestions. I've tried to explain the reasons for the differences on the web page. Since you don't want to use an rc tag -- even rc0? -- maybe some other git tag could be used to flag merge window ended. Please see above - I feel it would be wrong, as the merge window closed state is nothing that has a direct representation in our git tree. A -pre, maybe. If there's some obvious indicator there, you wouldn't need to update the wiki except maybe to summarize key points of the process you want to publicize. And contributors wouldn't be scratching their heads, or starting long discussions on the list. ;) But this discussion is/was a good thing to have! 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 Open the pod bay doors, HAL.- Dave Bowman, 2001 ___ 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
Hi Ben,
Ben Warren wrote:
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.
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?
- 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'.
What I personally find essential for patch submitters is the patch
dealing by custodian. It should be consistent and by this somehow
predictable. This helps patch submitters to get a feeling for 'this
patch has only a chance while merge window is open' or 'it's worth
sending this patch immediately, it will have a chance to be merge now'.
What confuses me is something like patch A is applied short time after
sent, patch B will be eventually applied later to next, patch C gets
no comments. With A and B doing the same stuff, and maybe C sent before A.
I can't say for sure if this is how all branches are
handled, though.
Let's wait for Jean-Christophe opinion.
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
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
Hi Dirk,
Dirk Behme wrote:
Hi Ben,
Ben Warren wrote:
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.
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?
I agree that cleanup patches should have more flexibility.
- What's about patches that are sent while open merge window or
before, but need some update cycles and are finalized while rc?
My policy is to look at the timestamp of the first revision. If it's
during the merge window, follow-on versions are OK too.
- 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'.
Well, since communication about the window state is rare at best, a good
argument can be made for flexibility here.
What I personally find essential for patch submitters is the patch
dealing by custodian. It should be consistent and by this somehow
predictable. This helps patch submitters to get a feeling for 'this
patch has only a chance while merge window is open' or 'it's worth
sending this patch immediately, it will have a chance to be merge now'.
Sure - consistency would be great. Unfortunately every custodian has
his own approach and it's a volunteer workforce. Definitely a goal
worth pursuing, though.
What confuses me is something like patch A is applied short time after
sent, patch B will be eventually applied later to next, patch C gets
no comments. With A and B doing the same stuff, and maybe C sent
before A.
Yeah, better and quicker feedback is a goal we should all be working
towards. Obviously small, trivial patches are easier to review than new
drivers, and so are typically applied more quickly.
I can't say for sure if this is how all branches are
handled, though.
Let's wait for Jean-Christophe opinion.
Best regards
Dirk
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
Dear Dirk, In message 49f2b6b9.7040...@googlemail.com you 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). When the merge window opens again, next goes to master and the fun starts again. Yes, this is my basic understanding, too. Mine, too. Note however that I will not always and not automatically and not exactly at the end of the merge window create a next branch, but I'm in a somewhat specialposition anyway. 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? They can, if the custodian accepts it, and.or if there is consensus on the ML. - What's about patches that are sent while open merge window or before, but need some update cycles and are finalized while rc? These should go in. People who put a lot of effort in their planning should not suffer from the fact that a custodian is slow on answering or reviewing their patches. Everything that has been sent to the list before the end of the MW should go in. - 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'. Patch acceptance is not as critical as a financial transaction, or such. So if there is a slight delay, the custodian is free to turn a blind eye and accept it anyway. The idea of the development process is to make it foreseeable and plannable, but not to become a PITA or to slow down development. It makes much more sense if an engineer spends another day on testing and cleanup and submits the patch a couple of hours late, instead of submitting a green patch which will waste efforts from several prople during several rounds of review and reposts. What I personally find essential for patch submitters is the patch dealing by custodian. It should be consistent and by this somehow predictable. This helps patch submitters to get a feeling for 'this patch has only a chance while merge window is open' or 'it's worth sending this patch immediately, it will have a chance to be merge now'. But this should be clear: if sent while the merge indow is open, new stuff can go in. If the MW is closed, new stuff may go into next (if the respective custodian runs a next branch), otherwise it has to wait until the next MW. Bug fixes can go in any time. What confuses me is something like patch A is applied short time after sent, patch B will be eventually applied later to next, patch C gets no comments. With A and B doing the same stuff, and maybe C sent before A. I agree that this is not nice. In any case, there should be some comment from the respective custodian which makes *clear* what the patch state is. Even a I have no time now, will look into it later is better than nothing. Also, if there are remarks to a patch, these should leave no doubt if they were just comments and the patch will be accepted anyway, or if the patch should be reworked/resubmitted, or if the patch was rejected without chance to be included at all. I can't say for sure if this is how all branches are handled, though. Let's wait for Jean-Christophe opinion. Well, his opinion is one thing. But I think we can also expect from Jean-Christophe as ARM custodian that he delivers clear and under- standable feedback to all patch submitters. 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 Make it right before you make it faster. ___ 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
Dear David, in message 200904250555.17450.davi...@pacbell.net you wrote: I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.) I'm not going to push this information down people's throats. I love living free. Those who want that information can pick it up, those who don't will not get bothered. Is it really too much to ask that people have a look at the U-Boot web page every now and then? Is it really so difficult to find our when the merge window ends? Just type u-boot merge window at google and click on the very first link. Maybe I pout a little more meaning in the words release candiate. ISTR that Linus has said on occasion that RC doesn't mean release candidate! He. This is his interpretation, then. I take the freedom to use a different one :-) You're not actually running the merge window quite like Linux does; that backlog is one differentiator. Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former. That's why we still have no rc in the current release cycle. May be worth reconsidering that, if for no other reason than to make intermedite milestones less opaque ... example, there was no suitably titled announcement in the list archives that the 2009.05 release got re-labeled, but I did eventually find http://lists.denx.de/pipermail/u-boot/2009-April/050339.html Yes, that was when we discussed the change. I edited the web page within the same hour, IIRC. When the RC label just means we only integrate bugfixes now, that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know. Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included. 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 A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. - Seneca ___ 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
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.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.
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.
___
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
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090425170829.ga30...@game.jcrosoft.org you wrote: - 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 How do you reliably find out that this is the case? 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 most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ___ 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
On 19:30 Sat 25 Apr , Wolfgang Denk wrote: Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090425170829.ga30...@game.jcrosoft.org you wrote: - 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 How do you reliably find out that this is the case? the patch is not finish and will clearly not work on the hard I've no example except a patch will is more a RFC than a really patch I've in mind Best Regards, J. ___ 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
Hi Wolfgang, On Saturday 25 April 2009, Wolfgang Denk wrote: in message 200904250555.17450.davi...@pacbell.net you wrote: I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.) I'm not going to push this information down people's throats. I love living free. Those who want that information can pick it up, those who don't will not get bothered. Is it really too much to ask that people have a look at the U-Boot web page every now and then? It's not on the front page, which is where for example you'll see status for Linux (www.kernel.org) or GCC (gcc.gnu.org). And it's not visible in the source tree either. Is it really so difficult to find our when the merge window ends? By observation: yes. But also, when you *do* find the Official Statment it does so in reference to Linux processes ... which make that state very easy to find, via the rc1 git tags. Just type u-boot merge window at google and click on the very first link. Several other key infrastructure projects make it easy to find that info even without using a search engine. As a developer, I'd be more likely to look at the GIT summary for status of the GIT tree; its normally the first place to look for such things. Maybe I pout a little more meaning in the words release candiate. ISTR that Linus has said on occasion that RC doesn't mean release candidate! He. This is his interpretation, then. I take the freedom to use a different one :-) You won't find SuSE, RedHat, or Canonical using an rc1 kernel for even a beta distribution ... ;) You're not actually running the merge window quite like Linux does; that backlog is one differentiator. Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former. And Linux has had years to develop -- and motivate! -- its merge procedures ... it's a different team and process. Processes need constant tweaking though. And your process page strongly suggests you're using the Linux processes. Hence surprise and confusion when you aren't quite doing so, from folk who use those processes daily. Easily addressed though ... that web page can point out some differences. Make a few small things *obviously* different, and people will assume that other things may also differ. When the RC label just means we only integrate bugfixes now, that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know. Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included. I couldn't stop you, of course. All I'm doing is pointing out what others have also pointed out: that the current process is a bit opaque about some key points. And I'm trying to help with some small suggestions. Since you don't want to use an rc tag -- even rc0? -- maybe some other git tag could be used to flag merge window ended. A -pre, maybe. If there's some obvious indicator there, you wouldn't need to update the wiki except maybe to summarize key points of the process you want to publicize. And contributors wouldn't be scratching their heads, or starting long discussions on the list. ;) - 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
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: For me when the first version of a [patch] 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. Wiki might usefully include this as part of that release cycle page that Wolfgang pointed out: * Bug fixes coming in after a merge window closes may still be included in the upcoming release if they are high enough priority. * Other patches coming in after the merge window will be held until the next merge window, possibly in a -next branch of a custodian tree. * Maintainers may, infrequently, make exceptions to those merge policies. It'd still be good to make the merge window ended state more visible, e.g. through *some* GIT tag. IMNSHO. - 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
Wolfgang Denk wrote: Dear Ben Warren, In message 49f2bed7.9070...@gmail.com you wrote: - 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'. Well, since communication about the window state is rare at best, a good argument can be made for flexibility here. While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and then tell me what exactly is not clear enough. With the discussion I think we can answer this question now with a short summary: a) All information is there b) Some people feel that copying this already available info to mailing list would ... just add a lot of noise to the ML, without any real new information .. c) On the other hand, some people seem to have the feeling that status updates aren't yet visible enough that the current process is a bit opaque about some key points ... IRC channel ... it seems that that's where the real action happens While my feeling tends to (c), too (this is why I e.g. asked for an IRC log), I accept (b) and agree with (a). Many thanks for this discussion, it already helped a lot, and best regards Dirk P.S.: Sorry if I didn't cite your argument or missed an essential one ;) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[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
