| Message ID | 1309289196-5718-1-git-send-email-vapier@gentoo.org |
|---|---|
| State | Rejected |
| Delegated to: | Wolfgang Denk |
| Headers | show |
Dear Mike Frysinger, In message <1309289196-5718-1-git-send-email-vapier@gentoo.org> you wrote: > All of thse patches have been posted previously, and no one has > given feedback, so here they are in a handy branch for you to pull. > > The following changes since commit b1af6f532e0d348b153d5c148369229d24af361a: > > Prepare v2011.06 (2011-06-27 22:22:42 +0200) > > are available in the git repository at: > git://www.denx.de/git/u-boot-blackfin.git post Please stop reposting patches without reference or patch version or change logs. Please consider all these postings to be NAKed. Please stick to the rules. These apply to everbody, including you. Even more so to you, as you have the experience and knowledge so that you actually should be aware of how these things get done. Also, after posting a patch series you MUST allow for review time. Um... you are reposting old patches unchanged? Now this is a really stupid thing to do - please stop doing that. Best regards, Wolfgang Denk
On Wednesday, June 29, 2011 17:21:46 Wolfgang Denk wrote: > Please stick to the rules. These apply to everbody, including you. > Even more so to you, as you have the experience and knowledge so that > you actually should be aware of how these things get done. you'll need to revise the wiki then as this really isnt how the linux workflow works. i dont know which patches exactly have been posted, which had feedback and were revised, etc... so i just posted the entire set that havent been merged fresh in case people missed things the first time around -- as is done on lkml. since most likely nothing is going to get changed (again) in the next two weeks, i'll simply rebase the branches and send another pull request. -mike
Dear Mike Frysinger, In message <201106291930.48377.vapier@gentoo.org> you wrote: > > On Wednesday, June 29, 2011 17:21:46 Wolfgang Denk wrote: > > Please stick to the rules. These apply to everbody, including you. > > Even more so to you, as you have the experience and knowledge so that > > you actually should be aware of how these things get done. > > you'll need to revise the wiki then as this really isnt how the linux workflow > works. ... I see no need to change anything, as the wiki represents how OUR workflow works. Please don't start applying random rules. > ... i dont know which patches exactly have been posted, which had feedback > and were revised, etc... Then please get a clue. If you don't maintain your own copies of such mails, then you can always refer to any of the mailing list archives. And of course there is patchwork, which nicely collects all messages that are related to a patch. All you have to is looking there. > ... so i just posted the entire set that havent been > merged fresh in case people missed things the first time around -- as is done > on lkml. I don't care if this is done like this on lkml. I consider it a stupid thing to do, as there is no indication in this repost 1) that this has been posted before, 2) to which mail thread a patch might refer to, 3) if this is just an unchanged repost and 4) if you made any changes, what these changes might be. I will definitely not invest any time in trying to find this out. We have clear rules how to post patches and updated versions of patches, and I ask you again to stick to these rules. Reposting patches - changed or unchanged - without any additional commend will receive immediate NAKs. > since most likely nothing is going to get changed (again) in the next two > weeks, i'll simply rebase the branches and send another pull request. I will not pull any patches that have been NAKed, and these are. And any similar repostings will be NAKed as well. If you want to do something useful, then apply the original patches, and make sure to reference these properly. Thanks. Wolfgang Denk
On Thu, Jun 30, 2011 at 06:29, Wolfgang Denk wrote: > Mike Frysinger wrote: >> On Wednesday, June 29, 2011 17:21:46 Wolfgang Denk wrote: >> > Please stick to the rules. These apply to everbody, including you. >> > Even more so to you, as you have the experience and knowledge so that >> > you actually should be aware of how these things get done. >> >> you'll need to revise the wiki then as this really isnt how the linux workflow >> works. ... > > I see no need to change anything, as the wiki represents how OUR > workflow works. > > Please don't start applying random rules. i'm not applying "random" rules. the workflow is generally modeled after the linux workflow, and the wiki explicitly has a section called "Differences to Linux Development Process". this common linux workflow was not mentioned in the differences section. > If you want to do something useful, then apply the original patches, > and make sure to reference these properly. except that they already are the original ones -mike
Dear Mike Frysinger, In message <BANLkTi=PoSnG11pLWC11Xv=HVO_pYQOR0A@mail.gmail.com> you wrote: > > > If you want to do something useful, then apply the original patches, > > and make sure to reference these properly. > > except that they already are the original ones Then why did you repost them? This is completely stupid, and I never want to see this again. And why do you think the rules for posting patches don't apply to you? Wolfgang Denk
On Thu, Jun 30, 2011 at 11:38, Wolfgang Denk wrote: > Mike Frysinger wrote: >> > If you want to do something useful, then apply the original patches, >> > and make sure to reference these properly. >> >> except that they already are the original ones > > Then why did you repost them? i already explained why in the thread. i just went through patchwork and d/l-ed the ones posted there and compared to my local tree to come to the conclusion that everything has already been posted (which is something i was not sure of when i sent things out a few days ago). it was a pita, but a requirement you stipulated. > And why do you think the rules for posting patches don't apply to > you? i never said that, and i already explained why i did what i did -mike
Dear Mike Frysinger, In message <BANLkTimMPtK0gyhRGammL0igYKsB0O2HCA@mail.gmail.com> you wrote: > > i just went through patchwork and d/l-ed the ones posted there and > compared to my local tree to come to the conclusion that everything > has already been posted (which is something i was not sure of when i > sent things out a few days ago). it was a pita, but a requirement you > stipulated. As a result of this action you could have come up with a branch that includes all the stuff that "has already been posted". There was no need nor any benefit from reposting the stuff again. On contrary, it is just wasting time and resources. > > And why do you think the rules for posting patches don't apply to > > you? > > i never said that, and i already explained why i did what i did Then please follow the rules. Don't repost other people's patches unchanged; and if you change them, provide proper indication in the Subject and a patch's change log. Best regards, Wolfgang Denk
On Thu, Jun 30, 2011 at 11:49, Wolfgang Denk wrote: > Mike Frysinger wrote: >> i just went through patchwork and d/l-ed the ones posted there and >> compared to my local tree to come to the conclusion that everything >> has already been posted (which is something i was not sure of when i >> sent things out a few days ago). it was a pita, but a requirement you >> stipulated. > > As a result of this action you could have come up with a branch that > includes all the stuff that "has already been posted". There was no > need nor any benefit from reposting the stuff again. On contrary, it > is just wasting time and resources. i often post misc patches all over which frequently get forgotten, and so i roll them up into a dedicated branch for you to pull. and in the past, you said you liked that. so now you're saying that my only option is to ping multiple patches over time until you notice. that sounds like more of a waste. -mike
Dear Mike Frysinger, In message <BANLkTinWfOUUBM8oJRuTZpX2N6ADTZTZ+A@mail.gmail.com> you wrote: > > >> i just went through patchwork and d/l-ed the ones posted there and > >> compared to my local tree to come to the conclusion that everything > >> has already been posted (which is something i was not sure of when i > >> sent things out a few days ago). =A0it was a pita, but a requirement you > >> stipulated. > > > > As a result of this action you could have come up with a branch that > > includes all the stuff that "has already been posted". =A0There was no > > need nor any benefit from reposting the stuff again. =A0On contrary, it > > is just wasting time and resources. > > i often post misc patches all over which frequently get forgotten, and > so i roll them up into a dedicated branch for you to pull. and in the > past, you said you liked that. Indeed, such a branch can be helpful. Also a pull request for it. But we're talking about the _original_ patches. > so now you're saying that my only option is to ping multiple patches > over time until you notice. that sounds like more of a waste. You misunderstand. Best regards, Wolfgang Denk
On Thu, Jun 30, 2011 at 17:10, Wolfgang Denk wrote: > Indeed, such a branch can be helpful. Also a pull request for it. But > we're talking about the _original_ patches. and that's what my serial/post/sf patches ended up being. should i change the status for them in patchwork from "rejected" to "new" ? -mike
Dear Mike Frysinger, In message <BANLkTimNnd7SS3K4ovEKNFV3TytGz6JzgQ@mail.gmail.com> you wrote: > On Thu, Jun 30, 2011 at 17:10, Wolfgang Denk wrote: > > Indeed, such a branch can be helpful. Also a pull request for it. =A0But > > we're talking about the _original_ patches. > > and that's what my serial/post/sf patches ended up being. should i You don't want to understand, right? You posted _new_ patches. There is a chance that these might actually be identical to any previously posted ones, but my time is way too precious that I would spend a single second on checking this, especially when you ignore all rules (version marker in the Subject, change log in the comment section). > change the status for them in patchwork from "rejected" to "new" ? Try it, if you really want to see how I react when someone really p*sses me off. I have already wasted way too much time on this stupid issue. I do not intend to continue this discussion. Wolfgang Denk
On Thu, Jun 30, 2011 at 18:57, Wolfgang Denk wrote: > Mike Frysinger wrote: >> On Thu, Jun 30, 2011 at 17:10, Wolfgang Denk wrote: >> > Indeed, such a branch can be helpful. Also a pull request for it. =A0But >> > we're talking about the _original_ patches. >> >> and that's what my serial/post/sf patches ended up being. should i > > You don't want to understand, right? You posted _new_ patches. > There is a chance that these might actually be identical to any > previously posted ones, but my time is way too precious that I would > spend a single second on checking this, especially when you ignore > all rules (version marker in the Subject, change log in the comment > section). and like i *already* said, i verified that the patches just posted match the ones already posted in the past by downloading them from patchwork and doing a diff on them. > I have already wasted way too much time on this stupid issue. I do > not intend to continue this discussion. so basically you're permanently NAK-ing all my patches even though i'm trying to find a way forward. awesome. -mike
Dear Mike Frysinger, In message <BANLkTim2vo8vrSZWWxGnLf8N2_gqBHUVSQ@mail.gmail.com> you wrote: > > so basically you're permanently NAK-ing all my patches even though i'm > trying to find a way forward. awesome. It's awsome how you manage to continue to ignore the documented rules, even after I explained them ten times to you. You are wasting my time. Wolfgang Denk
On Friday, July 01, 2011 00:36:59 Wolfgang Denk wrote: > Mike Frysinger wrote: > > so basically you're permanently NAK-ing all my patches even though i'm > > trying to find a way forward. awesome. > > It's awsome how you manage to continue to ignore the documented rules, > even after I explained them ten times to you. i'm not ignoring any rules. you said you dont want dumps of patches that havent been changed and lack pointing back to previous sets. fine. you also said you only want pull requests of patches that match the patches previously posted to the list, and based on that you NAK-ed my pulls. i then researched and clarified that all the pulls match exactly the patches that were in patchwork before the fresh dumps on June 28th. pretend the patch dumps for these branches didnt happen on June 28th, and the pull requests would still be exactly the same. yet you still refuse to take the pull requests and provide no reason as to why. you only say that i'm "wasting your time" with no backing logic and no indication as to how to move forward. i cant go back in time and unsend the patches that have already hit the list. -mike
Dear Mike Frysinger, In message <201107011927.38666.vapier@gentoo.org> you wrote: > > i'm not ignoring any rules. you said you dont want dumps of patches that > havent been changed and lack pointing back to previous sets. fine. http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions > yet you still refuse to take the pull requests and provide no reason as to > why. you only say that i'm "wasting your time" with no backing logic and no > indication as to how to move forward. i cant go back in time and unsend the > patches that have already hit the list. Unsend patches? I suggest you take a time-out of a few days, and then re-read this thread. If you still don't understand, then please ask somebody else to explain it to you. I give up here. Wolfgang Denk
On Sunday, July 03, 2011 18:30:05 Wolfgang Denk wrote: > Mike Frysinger wrote: > > i'm not ignoring any rules. you said you dont want dumps of patches that > > havent been changed and lack pointing back to previous sets. fine. > > http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions which is irrelevant like i already said multiple times -- these patches arent updated > > yet you still refuse to take the pull requests and provide no reason as > > to why. you only say that i'm "wasting your time" with no backing logic > > and no indication as to how to move forward. i cant go back in time and > > unsend the patches that have already hit the list. > > Unsend patches? I suggest you take a time-out of a few days, and > then re-read this thread. If you still don't understand, then please > ask somebody else to explain it to you. you seem to be ignoring the points i'm making -mike
Dear Mike Frysinger, In message <201107042125.54555.vapier@gentoo.org> you wrote: > > > http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions > > which is irrelevant like i already said multiple times -- these patches arent > updated So there is zero reason for resending. > you seem to be ignoring the points i'm making Wrong, twice. First, you are not making any points. You are just repeating the same rogation. Second, I'm on the verge of ignoring you. Wolfgang Denk
On Tuesday, July 05, 2011 00:42:13 Wolfgang Denk wrote: > Mike Frysinger wrote: > > > http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versi > > > ons > > > > which is irrelevant like i already said multiple times -- these patches > > arent updated > > So there is zero reason for resending. you already said that's what you want, and i already said "OK", which gets us back to what i already asked: if the pull requests reflect the old patches posted to the list before the resend on June 28th, then why cant they be changed from "rejected" to "new" ? -mike
Dear Mike Frysinger, In message <201107050214.11960.vapier@gentoo.org> you wrote: > > you already said that's what you want, and i already said "OK", which gets us > back to what i already asked: if the pull requests reflect the old patches > posted to the list before the resend on June 28th, then why cant they be > changed from "rejected" to "new" ? Your bogus repostings are rejected, not the original patches. Wolfgang Denk
On Tuesday, July 05, 2011 05:59:56 Wolfgang Denk wrote: > Mike Frysinger wrote: > > you already said that's what you want, and i already said "OK", which > > gets us back to what i already asked: if the pull requests reflect the > > old patches posted to the list before the resend on June 28th, then why > > cant they be changed from "rejected" to "new" ? > > Your bogus repostings are rejected, not the original patches. so since my pull requests are actually the original patches, i can go ahead and change them from "rejected" to "new" ? or should i just send new pull requests ? -mike
Dear Mike Frysinger, In message <201107051332.55970.vapier@gentoo.org> you wrote: > > > Your bogus repostings are rejected, not the original patches. > > so since my pull requests are actually the original patches, i can go ahead > and change them from "rejected" to "new" ? or should i just send new pull > requests ? This has already been answered. You are wasting my time. Stop it, now. This is my last message in this thread. Try to get help elsewhere. I got better things to do. Wolfgang Denk
On Tuesday, July 05, 2011 17:54:32 Wolfgang Denk wrote: > Mike Frysinger wrote: > > > Your bogus repostings are rejected, not the original patches. > > > > so since my pull requests are actually the original patches, i can go > > ahead and change them from "rejected" to "new" ? or should i just send > > new pull requests ? > > This has already been answered. You are wasting my time. Stop it, > now. your logic makes no sense. you say you are fine with the original patches, but i cant send pull requests of the original patches. i guess i'll have to wait for you to pick the individual patches out of patchwork then. -mike
All of thse patches have been posted previously, and no one has given feedback, so here they are in a handy branch for you to pull. The following changes since commit b1af6f532e0d348b153d5c148369229d24af361a: Prepare v2011.06 (2011-06-27 22:22:42 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git post Mike Frysinger (5): post: fix up I/O helper usage post: add gpio hotkey support post: use ARRAY_SIZE post: new nor flash test serial: implement common uart post test common/serial.c | 90 +++++++++++++++++++++ include/post.h | 5 +- include/serial.h | 5 + post/board/lwmon/sysmon.c | 2 +- post/cpu/mpc8xx/ether.c | 4 +- post/cpu/mpc8xx/spr.c | 3 +- post/cpu/mpc8xx/uart.c | 4 +- post/cpu/ppc4xx/spr.c | 3 +- post/drivers/Makefile | 2 +- post/drivers/flash.c | 107 +++++++++++++++++++++++++ post/drivers/memory.c | 2 +- post/lib_powerpc/andi.c | 3 +- post/lib_powerpc/cmp.c | 3 +- post/lib_powerpc/cmpi.c | 3 +- post/lib_powerpc/cr.c | 12 +-- post/lib_powerpc/fpu/mul-subnormal-single-1.c | 2 +- post/lib_powerpc/load.c | 3 +- post/lib_powerpc/multi.c | 2 +- post/lib_powerpc/rlwimi.c | 3 +- post/lib_powerpc/rlwinm.c | 3 +- post/lib_powerpc/rlwnm.c | 3 +- post/lib_powerpc/srawi.c | 3 +- post/lib_powerpc/store.c | 3 +- post/lib_powerpc/three.c | 3 +- post/lib_powerpc/threei.c | 3 +- post/lib_powerpc/threex.c | 3 +- post/lib_powerpc/two.c | 3 +- post/lib_powerpc/twox.c | 3 +- post/post.c | 23 +++++- post/tests.c | 17 ++++- 30 files changed, 269 insertions(+), 56 deletions(-) create mode 100644 post/drivers/flash.c