[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.
This patch applies against the u-boot tree at git://www.jdl.com/software/u-boot-86xx.git
When CONFIG_OF_FLAG_TREE is set, the compiler complains that 'len' in do_bootm_linux() may be uninitialized. There is no possibility in the current code that len will get used uninitialized, but this fix follows the existing convention of setting both len and data to zero at the same time.
Signed-off-by: Grant Likely grant.likely@secretlab.ca --- common/cmd_bootm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 652d843..af949a3 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -623,7 +623,7 @@ #ifdef CONFIG_OF_FLAT_TREE /* Look for a '-' which indicates to ignore the ramdisk argument */ if (argc >= 3 && strcmp(argv[2], "-") == 0) { debug ("Skipping initrd\n"); - data = 0; + len = data = 0; } else #endif
In message 528646bc0610092323k748bfc45v13f53affd381e1a9@mail.gmail.com you wrote:
This patch applies against the u-boot tree at git://www.jdl.com/software/u-boot-86xx.git
Please do NOT post patches here against code that is not in the official source tree.
Best regards,
Wolfgang Denk
On 10/10/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610092323k748bfc45v13f53affd381e1a9@mail.gmail.com you wrote:
This patch applies against the u-boot tree at git://www.jdl.com/software/u-boot-86xx.git
Please do NOT post patches here against code that is not in the official source tree.
Where then should I take discussion that is directly related to improving the quality of the flattened device tree code held in that tree? Would you really prefer that discussion to be taken off line and then a full patch set be dumped on the mailing list wholesale?
The fdt support patches are non-trivial. You've already rejected them here. Why do you want to eliminate an effort to improve them from this list?
I clearly indicated that this patch is not for mainline.
cheers, g.
In message 528646bc0610100013h7a7fd1d3pe66473431000dc28@mail.gmail.com you wrote:
Where then should I take discussion that is directly related to improving the quality of the flattened device tree code held in that tree? Would you really prefer that discussion to be taken off line
No, definitely not. Discussing the stuff here is just fine. Also posting patches here is fine (and the only "official" way for patch submissions so far).
and then a full patch set be dumped on the mailing list wholesale?
If this is a clean set of patches this is just fine with me. Actually this is the current "official" way to do it. Even if you provide a git repo for easy merging, you are still required to post the set of patches here on the list so everybody can see and discuss these.
It is MUCH easier to review a patch than analyzing what might have been change in another repo.
The fdt support patches are non-trivial. You've already rejected them here. Why do you want to eliminate an effort to improve them from this list?
I definitely don't want to do this.
But on the other hand, I think it makes no sense if we start posting patches here that are against N private repositories somewhere else.
If you find a problem with the code, then post a follow-up (eventually including an incremental patch) against a patch that was posted here on this mailing list.
Best regards,
Wolfgang Denk
On 10/10/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610100013h7a7fd1d3pe66473431000dc28@mail.gmail.com you wrote:
Where then should I take discussion that is directly related to improving the quality of the flattened device tree code held in that tree? Would you really prefer that discussion to be taken off line
No, definitely not. Discussing the stuff here is just fine. Also posting patches here is fine (and the only "official" way for patch submissions so far).
Ok, which leads to the issue of which patches are allowed to be posted here.
and then a full patch set be dumped on the mailing list wholesale?
If this is a clean set of patches this is just fine with me. Actually this is the current "official" way to do it. Even if you provide a git repo for easy merging, you are still required to post the set of patches here on the list so everybody can see and discuss these.
It is MUCH easier to review a patch than analyzing what might have been change in another repo.
Agreed
The fdt support patches are non-trivial. You've already rejected them here. Why do you want to eliminate an effort to improve them from this list?
I definitely don't want to do this.
But on the other hand, I think it makes no sense if we start posting patches here that are against N private repositories somewhere else.
And this is where we diverge. Why not? Many other projects do so, the Linux kernel being the most notable example.
If you find a problem with the code, then post a follow-up (eventually including an incremental patch) against a patch that was posted here on this mailing list.
The whole point of git is that we *can* develop features off of mainline in N private repos and easily merge them back in when they are ready. The off-mainline work needs peer-review just as much as patches for mainline (especially when they're my patches). As you agree, patches to the mailing list is the easiest way to discuss changes, but they don't always directly map to an increment to another patch. Once the off-mainline tree is ready, a patch can easily be generated that describes the sum of changes. Individual commits don't matter, only the sum of commits (for a single off-mainline tree).
Also, I think your contradicting your original statement:
Please do NOT post patches here against code that is not in the official source tree"
Are you saying that patches to non-mainline code is only acceptable if it's are reply to a mainline patch? That seems rather arbitrary to me. What if I have a change that builds on an off-mainline tree; but isn't a bug fix or enhancement. (for instance; I'm working on fdt support for the 5200; it builds on the fdt support that isn't in mainline, but it isn't a change to it). The off mainline tree is not yet accepted for merging, but I still want to get my changes out there for others to see/comment on.
Surely we can come to a compromise on this. Can we agree on a way to label non-mainline patches so that it is *explicit* that they are not for mainline?
Cheers, g.
In message 528646bc0610102309j6fcf7ed4n74e6af179d21f42b@mail.gmail.com you wrote:
Ok, which leads to the issue of which patches are allowed to be posted here.
Patches against the "official" U-Boot source tree.
But on the other hand, I think it makes no sense if we start posting patches here that are against N private repositories somewhere else.
And this is where we diverge. Why not? Many other projects do so, the Linux kernel being the most notable example.
Why not? I want to have the information all in one place, and not scattered around in hundrets of unrelated repositories, all in a different state, all with diferent problems and issues to track.
The whole point of git is that we *can* develop features off of mainline in N private repos and easily merge them back in when they are ready. The off-mainline work needs peer-review just as much as patches for mainline (especially when they're my patches). As you agree, patches to the mailing list is the easiest way to discuss changes, but they don't always directly map to an increment to another patch. Once the off-mainline tree is ready, a patch can easily be generated that describes the sum of changes. Individual commits don't matter, only the sum of commits (for a single off-mainline tree).
This assumes that the "other" repository is kept in a clean state, but this is usually not the case. What happens is this: somebody starts working in his own repo, and does so for a long time without review on the list. Over time, a lot of problems in his code sneak in. When he finally announces his repo and ask to have it merged into the public tree he says: Ummm, now it's too late, it would be too much work to fix all these issues and to re-do all the checkins [remember the case of the missing CHANGELOG entries in Jon's tree - this cannot be fixed afterwards as these have to be done for each checkin].
Also, I think your contradicting your original statement:
Please do NOT post patches here against code that is not in the official source tree"
Are you saying that patches to non-mainline code is only acceptable if it's are reply to a mainline patch? That seems rather arbitrary to me. What if I have a change that builds on an off-mainline tree; but isn't a bug fix or enhancement. (for instance; I'm working on fdt
Ummm... I don't understand. If it's neither a fix nor an enhancement I see no need for a change at all ;-) And if it's againt someboidy else's tree, then please discuss it with the maintainer of that tree.
support for the 5200; it builds on the fdt support that isn't in mainline, but it isn't a change to it). The off mainline tree is not yet accepted for merging, but I still want to get my changes out there for others to see/comment on.
It's simple: if you cange code that's in the "official" tree, then post patches here. Maybe even patches on top of other patches that have been posted here.
If you are using some other repository, then please discuss this with the maintainer of this other repo. I'm not willing to comment on code which is unknown to me.
Surely we can come to a compromise on this. Can we agree on a way to label non-mainline patches so that it is *explicit* that they are not for mainline?
If the patches that lead to this "non-mainline" tree have not been posted here before, I don't want to see discussion of this "non-mainline" tree here either.
Best regards,
Wolfgang Denk
On 10/11/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610102309j6fcf7ed4n74e6af179d21f42b@mail.gmail.com you wrote:
Ok, which leads to the issue of which patches are allowed to be posted here.
Patches against the "official" U-Boot source tree.
And this is where we diverge. Why not? Many other projects do so, the Linux kernel being the most notable example.
Why not? I want to have the information all in one place, and not scattered around in hundrets of unrelated repositories, all in a different state, all with diferent problems and issues to track.
Who's talking about hundreds of unrelated repositories? We're talking about a handful of *related* repositories. Plus, it must be understood that if anyone uses a non-mainline tree, it is *their* responsibility to keep that repo up to date.
Anyone who asks to merge an out of sync repo should rightly be flamed.
This assumes that the "other" repository is kept in a clean state, but this is usually not the case. What happens is this: somebody starts working in his own repo, and does so for a long time without review on the list. Over time, a lot of problems in his code sneak in. When he finally announces his repo and ask to have it merged into the public tree he says: Ummm, now it's too late, it would be too much work to fix all these issues and to re-do all the checkins
True, but that's not your issue. Flame away when someone posts out of date patches. The holder of the non-mainline tree is responsible to make sure his submissions to mainline are clean.
[remember the case of the missing CHANGELOG entries in Jon's tree - this cannot be fixed afterwards as these have to be done for each checkin].
<digress>Why are you so concerned with a manual CHANGELOG file? Isn't that part of the reason to use a good scm? Updating the Changelog by hand is just busywork when the tool will generate changelog information for you.</digress>
Also, I think your contradicting your original statement:
Please do NOT post patches here against code that is not in the official source tree"
Are you saying that patches to non-mainline code is only acceptable if it's are reply to a mainline patch? That seems rather arbitrary to me. What if I have a change that builds on an off-mainline tree; but isn't a bug fix or enhancement. (for instance; I'm working on fdt
Ummm... I don't understand. If it's neither a fix nor an enhancement I see no need for a change at all ;-) And if it's againt someboidy else's tree, then please discuss it with the maintainer of that tree.
Which is what I want to do. What I'm hearing from you is that I am not welcome to do so on this list. I respect the fact that you are the maintainer of this list, and therefore can choose the list policies. However, I do think you are being short sighted in not welcoming discussion that is indirectly related to mainline (ie. under development, not ready for integration)
support for the 5200; it builds on the fdt support that isn't in mainline, but it isn't a change to it). The off mainline tree is not yet accepted for merging, but I still want to get my changes out there for others to see/comment on.
It's simple: if you cange code that's in the "official" tree, then post patches here. Maybe even patches on top of other patches that have been posted here.
If you are using some other repository, then please discuss this with the maintainer of this other repo. I'm not willing to comment on code which is unknown to me.
But you are not the only person on this list. There are others who are interested.
Surely we can come to a compromise on this. Can we agree on a way to label non-mainline patches so that it is *explicit* that they are not for mainline?
If the patches that lead to this "non-mainline" tree have not been posted here before, I don't want to see discussion of this "non-mainline" tree here either.
Thank you for making your position clear. I think your position is unreasonable and short sited, but this is your list and I will respect how you want to run it.
Cheers, g.
On 10/11/06, Grant Likely grant.likely@secretlab.ca wrote:
On 10/11/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610102309j6fcf7ed4n74e6af179d21f42b@mail.gmail.com you wrote:
This assumes that the "other" repository is kept in a clean state, but this is usually not the case. What happens is this: somebody starts working in his own repo, and does so for a long time without review on the list. Over time, a lot of problems in his code sneak in. When he finally announces his repo and ask to have it merged into the public tree he says: Ummm, now it's too late, it would be too much work to fix all these issues and to re-do all the checkins
True, but that's not your issue. Flame away when someone posts out of date patches. The holder of the non-mainline tree is responsible to make sure his submissions to mainline are clean.
I think it's common practice to have a separate branch for stuff to merge into mainline. Such a branch (called "for-wolfgang", for example) should be based off the latest mainline head and contain one commit for each logical change, i.e. the same rules apply here as for regular patches. After it has been either merged or NAK'ed by Wolfgang, it can be discarded and re-built, possibly with a different set of changes and based off a later mainline head.
This way, the master branch in the non-mainline tree can be kept linear without all the noise from pulling, reverting and fixing being visible in the mainline repository.
[remember the case of the missing CHANGELOG entries in Jon's tree - this cannot be fixed afterwards as these have to be done for each checkin].
With a non-linear merge branch, it's easy to alter existing commit messages, including CHANGELOG entries.
Haavard
In message 528646bc0610110830k7f29ab8jf319886dfa98683b@mail.gmail.com you wrote:
Who's talking about hundreds of unrelated repositories? We're talking about a handful of *related* repositories. Plus, it must be understood that if anyone uses a non-mainline tree, it is *their* responsibility to keep that repo up to date.
Agreed. Will they also take responsibility to answer related questions here on the list?
<digress>Why are you so concerned with a manual CHANGELOG file? Isn't that part of the reason to use a good scm? Updating the Changelog by hand is just busywork when the tool will generate changelog information for you.</digress>
Many of the users (at least many of those I have to deal with) don't use any SCM, at least not to work with the U-Boot code. Many of them just download a snapshot, typically a tarball from the FTP server.
The CHANGELOG file is important for such users to know what's there; I"m usually happy if they know how to run "diff" against two versions of that file to see what was changed :-( For me it's also important as I've seen quite a number of situations where the CHANGELOG file was the only way to reliably identify which exact version a (modified) tree was branched off.
I agree that we don't need it as long as everybody has an intact repository available. Unfortunately this is not always the case. At least not with the people I have to deal with :-(
Finally, I find it much faster to grep in the CHANGELOG than to run "git log" and search in the output.
Maybe there is a clever way to auto-generate the CHANGELOG from the commit message; I tried this once and failed. Ummm... just tried again and found that it's actually working when I use git-commit; however, it seems that cg-commit does not run the pre-commit hook. Maybe a cogito issue. I'll ask...
Which is what I want to do. What I'm hearing from you is that I am not welcome to do so on this list. I respect the fact that you are the maintainer of this list, and therefore can choose the list policies. However, I do think you are being short sighted in not welcoming discussion that is indirectly related to mainline (ie. under development, not ready for integration)
I understand your argument. But I'd rather have that we were all able to see the code we're discussing without need to clone another repository and to analyze what they changed and why, and which parts of this are intended for mainstream and which not, and which parts are ready or incomplete or under work. It's like the netiquette rules for quoting when replying to a message: it gives you some context. With a repo somewhere else it's IMHO more difficult to get such context than when you can reply to a message with a patch included and simply quote the relevant parts of that patch.
Maybe I'm not flexible enough, but I'd really prefer if the patches we're discussing have been posted to this list before.
But you are not the only person on this list. There are others who are interested.
You are right. Maybe we should just try how it works.
If the patches that lead to this "non-mainline" tree have not been posted here before, I don't want to see discussion of this "non-mainline" tree here either.
Thank you for making your position clear. I think your position is unreasonable and short sited, but this is your list and I will respect how you want to run it.
No, this is actually not what I want. I'm interested to reach some agreement we all can live with. If you (and others?) think my position is unreasonable I would at least like to understand why. I don't promise to change my mind ;-), but I do promise to seriously consider your arguments.
git makes it easy to generate and send patches, so what's wrong with asking that such patches have been posted here? At least this makes clear what this specific patch is intended for.
Also, it makes sure this stuff is archived somewhere. Such external repositories tend to disappear without notice, and I would like to be able to track down history any time later.
Best regards,
Wolfgang Denk
On 10/11/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610110830k7f29ab8jf319886dfa98683b@mail.gmail.com you wrote:
Who's talking about hundreds of unrelated repositories? We're talking about a handful of *related* repositories. Plus, it must be understood that if anyone uses a non-mainline tree, it is *their* responsibility to keep that repo up to date.
Agreed. Will they also take responsibility to answer related questions here on the list?
They should. If they do not, then the off-mainline tree is irrelevant to those who lurk here.
Many of the users (at least many of those I have to deal with) don't use any SCM, at least not to work with the U-Boot code. Many of them just download a snapshot, typically a tarball from the FTP server.
The CHANGELOG file is important for such users to know what's there; I"m usually happy if they know how to run "diff" against two versions of that file to see what was changed :-( For me it's also important as I've seen quite a number of situations where the CHANGELOG file was the only way to reliably identify which exact version a (modified) tree was branched off.
<snip>
Maybe there is a clever way to auto-generate the CHANGELOG from the commit message; I tried this once and failed. Ummm... just tried again and found that it's actually working when I use git-commit; however, it seems that cg-commit does not run the pre-commit hook. Maybe a cogito issue. I'll ask...
Hopefully this is fixable. It would certainly make developers lives easier. Alternately, can the changelog be generated at the time of tarball extraction? Of course, this would mean that the changelog no longer exists in the git repo. What are you using as a pre-commit hook?
Jon, do you have any experience with this?
Which is what I want to do. What I'm hearing from you is that I am not welcome to do so on this list. I respect the fact that you are the maintainer of this list, and therefore can choose the list policies. However, I do think you are being short sighted in not welcoming discussion that is indirectly related to mainline (ie. under development, not ready for integration)
I understand your argument. But I'd rather have that we were all able to see the code we're discussing without need to clone another repository and to analyze what they changed and why, and which parts of this are intended for mainstream and which not, and which parts are ready or incomplete or under work. It's like the netiquette rules for quoting when replying to a message: it gives you some context. With a repo somewhere else it's IMHO more difficult to get such context than when you can reply to a message with a patch included and simply quote the relevant parts of that patch.
Fair enough. However it is not always easy to do so. Let's take jdl's git tree as an example. The patches in that tree have been submitted to the mailing list over the last 6 months or so. I don't necessarily have that mailing list history in my inbox. Nor would I be familiar with those patches if I recently joined the ML. Also, additional patches have gone in overtop of the original patches so which do I reply to? Finally, while using git; if you apply a patch off the mailing list in mbox format; it uses the subject line and message body as the commit message. In which case you don't want the clutter of earlier patch fragments; those fragments are already in the tree!
So, the question still remains "How do I provide the appropriate context for an off-mainline patch?"
Some possible ideas: 1. Track down the original patch email. - Context is inline - labor intensive - In many cases it doesn't really capture the context. In the case of a working tree like jdl's, because such a long period of time has gone by, there is probably not a single logical patch to derive from. Patches have since gone in on top of the original patch. The context has changed, and the patch is only relevant against the context of the *sum of the changes* 2. Clearly label the patch as to which tree it applies to - Context is implicit in the target tree; but not in the email. - This assumes that the off-mainline maintainer/users are responsible to respond. 3. Keep the patches off the mailing list entirely and wait for the whole thing to be fully baked before reposting. - Discussion does not happen on the ML until the patches are reposted 4. Don't worry about it and post w/ no context - Gets you flamed. :-)
My preference is definitely #2. I guess my opinion is: development is going to occur in off-mainline trees regardless. Most of them are private (and therefore irrelevant to this discussion), but some like jdl's and the freescale trees are public. The changes have been around a long time, but they are still not in mainline. In this case, I do not think replying to one of the original patches is relevant or convenient due to additional changes applied on top, the amount of time that has passed, and the git workflow.
Also as an aside, I'm also assuming the that the mainline maintainer is *not* expected to comment on off-mainline patches (but is certainly welcome to).
Please note: I'm not talking about accepting those patches into mainline. The off mainline changes still need to be approved by you before being accepted into mainline. If I understand you correctly, you require that 'clean' patches be extracted from an off-mainline tree and posted to the ML before they will be accepted into mainline. Eventually, the patches I'm talking about will appear in mainline as part of the 'fully baked' patchset; submitted by the off-mainline maintainer; and subject to approval for mainline.
Maybe I'm not flexible enough, but I'd really prefer if the patches we're discussing have been posted to this list before.
Understood, and in most cases they probably have
But you are not the only person on this list. There are others who are interested.
You are right. Maybe we should just try how it works.
:)
If the patches that lead to this "non-mainline" tree have not been posted here before, I don't want to see discussion of this "non-mainline" tree here either.
Thank you for making your position clear. I think your position is unreasonable and short sited, but this is your list and I will respect how you want to run it.
On rereading my comment here, I realize it's harsher than I intended. I'm sorry. I just wanted to state my disagreement, but this statement could be read as a personal comment. I apologize.
No, this is actually not what I want. I'm interested to reach some agreement we all can live with. If you (and others?) think my position is unreasonable I would at least like to understand why. I don't promise to change my mind ;-), but I do promise to seriously consider your arguments.
Okay, then I misunderstood and I apologize.
git makes it easy to generate and send patches, so what's wrong with asking that such patches have been posted here? At least this makes clear what this specific patch is intended for.
I think that's fair (and probably already being done)
Also, it makes sure this stuff is archived somewhere. Such external repositories tend to disappear without notice, and I would like to be able to track down history any time later.
agreed.
Cheers, g.
Dear Grant,
in message 528646bc0610121208i2b9b3b4at8e7de8c0b3800276@mail.gmail.com you wrote:
Maybe there is a clever way to auto-generate the CHANGELOG from the commit message; I tried this once and failed. Ummm... just tried again and found that it's actually working when I use git-commit; however, it seems that cg-commit does not run the pre-commit hook. Maybe a cogito issue. I'll ask...
I asked, and received pretty clear statements: even if we'd use the pre-commit hook it wouldn't work as this run before editing the commit message. On the other hand, as long as we manually edit the commit message we can point EDITOR to some wrapper script. But also the general opinion about my idea was pretty clear. Linus himself wrote unequivocally: "Why? That's just stupid."
Hopefully this is fixable. It would certainly make developers lives easier. Alternately, can the changelog be generated at the time of tarball extraction? Of course, this would mean that the changelog no longer exists in the git repo. What are you using as a pre-commit hook?
Nothing yet. I thought about some script, but it seems it doesn't work. And my other idea of using git-format-patch + git-mailinfo + some custom script to re-play the sequence of commits with automatically editing the CHANGELOG before comitting is not as easy either since both format-patch and mailinfo have their own ideas how to reformat the commit message.
Jon, do you have any experience with this?
Fair enough. However it is not always easy to do so. Let's take jdl's git tree as an example. The patches in that tree have been submitted to the mailing list over the last 6 months or so. I don't necessarily have that mailing list history in my inbox. Nor would I
Ah, I see. This emanates from my own style of working - for me the mailing list archive is everything - history and patch database and task tracking system... On the other hand, there are mailing list archives at SF and gmane...
So, the question still remains "How do I provide the appropriate context for an off-mainline patch?"
I see your point.
My preference is definitely #2. I guess my opinion is: development is going to occur in off-mainline trees regardless. Most of them are private (and therefore irrelevant to this discussion), but some like jdl's and the freescale trees are public. The changes have been around a long time, but they are still not in mainline. In this case, I do not think replying to one of the original patches is relevant or convenient due to additional changes applied on top, the amount of time that has passed, and the git workflow.
You convinced me. Thanks for the explanation.
On rereading my comment here, I realize it's harsher than I intended. I'm sorry. I just wanted to state my disagreement, but this statement could be read as a personal comment. I apologize.
No offence taken. I often sound harsher than I intend, too. I know that lack of time is no real excuse, but I don't have a better one.
Okay, then I misunderstood and I apologize.
I'm glad to see we're discussing problems and solutions again. This is all I want.
Thanks.
Best regards,
Wolfgang Denk
On 10/12/06, Wolfgang Denk wd@denx.de wrote:
Dear Grant,
in message 528646bc0610121208i2b9b3b4at8e7de8c0b3800276@mail.gmail.com you wrote:
Maybe there is a clever way to auto-generate the CHANGELOG from the commit message; I tried this once and failed. Ummm... just tried again and found that it's actually working when I use git-commit; however, it seems that cg-commit does not run the pre-commit hook. Maybe a cogito issue. I'll ask...
I asked, and received pretty clear statements: even if we'd use the pre-commit hook it wouldn't work as this run before editing the commit message. On the other hand, as long as we manually edit the commit message we can point EDITOR to some wrapper script. But also the general opinion about my idea was pretty clear. Linus himself wrote unequivocally: "Why? That's just stupid."
Can we please just punt the in-tree CHANGELOG file? Please please please please?
Tarballs can always have it; It can always be generated in a local copy; But does it really need to be updated manually in every patch?
My preference is definitely #2. I guess my opinion is: development is going to occur in off-mainline trees regardless. Most of them are private (and therefore irrelevant to this discussion), but some like jdl's and the freescale trees are public. The changes have been around a long time, but they are still not in mainline. In this case, I do not think replying to one of the original patches is relevant or convenient due to additional changes applied on top, the amount of time that has passed, and the git workflow.
You convinced me. Thanks for the explanation.
:) Thanks, I appreciate your consideration.
On rereading my comment here, I realize it's harsher than I intended. I'm sorry. I just wanted to state my disagreement, but this statement could be read as a personal comment. I apologize.
No offence taken. I often sound harsher than I intend, too. I know that lack of time is no real excuse, but I don't have a better one.
Hooray. This is much better than flared tempers.
In message 528646bc0610121351q24766ce0oa8df5d07b9f79cc7@mail.gmail.com you wrote:
Can we please just punt the in-tree CHANGELOG file? Please please please please?
Old habits die hard...
Tarballs can always have it; It can always be generated in a local copy; But does it really need to be updated manually in every patch?
Ideally it would get updated automagically with each commit message :-)
You write: "Tarballs can always have it" - how? Normally I just type
cg-export [-r TREE_ID] some-file.tar.bz2
How do I get a file included that looks not too much different from the current CHANGELOG? Any suggestions?
Best regards,
Wolfgang Denk
On Tue, 2006-10-10 at 10:58 +0200, Wolfgang Denk wrote:
But on the other hand, I think it makes no sense if we start posting patches here that are against N private repositories somewhere else.
The set of patches which this applies to has been submitted several months ago, I think a follow up patch regarding a problem should be submitted to the list for all to see.
Is that not acceptable?
-Matthew
On 10/11/06, Matthew McClintock msm@freescale.com wrote:
On Tue, 2006-10-10 at 10:58 +0200, Wolfgang Denk wrote:
But on the other hand, I think it makes no sense if we start posting patches here that are against N private repositories somewhere else.
The set of patches which this applies to has been submitted several months ago, I think a follow up patch regarding a problem should be submitted to the list for all to see.
Is that not acceptable?
It's not just bug fix patches that are at issue here. I've got a new feature set which builds on the fdt patches. From what I'm hearing, those patches are not welcome here.
g.
In message 1160590939.5466.14.camel@localhost you wrote:
The set of patches which this applies to has been submitted several months ago, I think a follow up patch regarding a problem should be submitted to the list for all to see.
Is that not acceptable?
Yes of course it is. Not only acceptable, but appreciated.
I'd like to see some reference to the original posting, though (date and subject of posting or message ID or something like that). This is something I can deal with easily. I find it's much more time consuming if I have to clone a complete repository first.
Best regards,
Wolfgang Denk
On Tue, 2006-10-10 at 00:23 -0600, Grant Likely wrote:
This patch applies against the u-boot tree at git://www.jdl.com/software/u-boot-86xx.git
When CONFIG_OF_FLAG_TREE is set, the compiler complains that 'len' in do_bootm_linux() may be uninitialized. There is no possibility in the current code that len will get used uninitialized, but this fix follows the existing convention of setting both len and data to zero at the same time.
Signed-off-by: Grant Likely grant.likely@secretlab.ca
common/cmd_bootm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 652d843..af949a3 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -623,7 +623,7 @@ #ifdef CONFIG_OF_FLAT_TREE /* Look for a '-' which indicates to ignore the ramdisk argument */ if (argc >= 3 && strcmp(argv[2], "-") == 0) { debug ("Skipping initrd\n");
data = 0;
len = data = 0;#endif
I just checked in a patch which fixes a lot of compiler warnings including this one. Again, the tree lives at:
http://opensource.freescale.com/pub/scm/u-boot-85xx.git
Thanks Grant.
-Matthew
Dear Matthew,
in message 1160600548.5466.45.camel@localhost you wrote:
I just checked in a patch which fixes a lot of compiler warnings including this one. Again, the tree lives at:
Can't get it, though:
-> cg-update msm@freescale.com Fetching head... Fetching objects... Getting alternates list for http://opensource.freescale.com/pub/scm/u-boot-85xx.git/ Getting pack list for http://opensource.freescale.com/pub/scm/u-boot-85xx.git/ Getting index for pack f2707cbbd95d17a764ddf5e79a11758932b6126d error: Unable to get pack index http://opensource.freescale.com/pub/scm/u-boot-85xx.git//objects/pack/pack-f... transfer closed with 654675 bytes remaining to read Getting index for pack 970e42135b5a4dc766e8da99767cf5b91d2b3c71 Getting pack 970e42135b5a4dc766e8da99767cf5b91d2b3c71 which contains 7376eb87aaa601f728f9b8e5e9cd2711a67f529e error: Unable to find 88c8f4921fc47fb0eb2384b16586f1bd7f275be7 under http://opensource.freescale.com/pub/scm/u-boot-85xx.git/ Cannot obtain needed commit 88c8f4921fc47fb0eb2384b16586f1bd7f275be7 while processing commit 7376eb87aaa601f728f9b8e5e9cd2711a67f529e. progress: 0 objects, 0 bytes cg-fetch: objects fetch failed
Best regards,
Wolfgang Denk
In message 1160600548.5466.45.camel@localhost you wrote:
I just checked in a patch which fixes a lot of compiler warnings including this one. Again, the tree lives at:
OK, got it on second attempt.
OK, there are a fwew minor cosding style issues which I can fix easily. However, we have again the problem with the unmaintained CHANGELOG.
Do you have any suggestions how we can fix this?
Best regards,
Wolfgang Denk
On Thu, 2006-10-12 at 00:04 +0200, Wolfgang Denk wrote:
In message 1160600548.5466.45.camel@localhost you wrote:
I just checked in a patch which fixes a lot of compiler warnings including this one. Again, the tree lives at:
OK, got it on second attempt.
OK, there are a fwew minor cosding style issues which I can fix easily. However, we have again the problem with the unmaintained CHANGELOG.
Do you have any suggestions how we can fix this?
Best regards,
Wolfgang Denk
If you would like I can start over and recommit each patch. Do you have any better methods of updating the CHANGELOG for each patch?
-Matthew
Hi Matthew,
Matthew McClintock msm@freescale.com writes:
If you would like I can start over and recommit each patch. Do you have any better methods of updating the CHANGELOG for each patch?
Its probably* too late in this case, but in general stacked git lets you handle this efficently. You can maintain a stack of patches on top of the cloned official repo. When you think your done, commit the patches to a branch and publish it. If it needs further fixes, delete the branch, fix you patches repeat the commit and publish.
Regards
Markus Klotzbuecher
* There is a "stg uncommit" command, that allows you to turn a git commit into a stacked git patch, but I havn't used that one yet.
participants (5)
-
Grant Likely -
Haavard Skinnemoen -
Markus Klotzbücher -
Matthew McClintock -
Wolfgang Denk