[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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
-- 
1.4.2.rc2.g822a

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Today's robots are very primitive, capable of understanding  only  a
few  simple  instructions  such  as 'go left', 'go right', and 'build
car'."                                                  - John Sladek

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The man on tops walks a lonely street;  the  "chain"  of  command  is
often a noose.

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If you'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson  Space  Center,
Houston July 20, 1969, 7:27 P.M.

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Haavard Skinnemoen]

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

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain: an apparatus with which we think we think.    - Ambrose Bierce

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Matthew McClintock]

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

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Grant Likely]

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.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Matthew McClintock]

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;
>  		}
>  	else
>  #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

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

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:
> 
> http://opensource.freescale.com/pub/scm/u-boot-85xx.git

Can't get it, though:

-> cg-update msm at 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-f2707cbbd95d17a764ddf5e79a11758932b6126d.idx
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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There's only one kind of woman ..." "Or man, for  that  matter.  You
either believe in yourself or you don't."
	-- Kirk and Harry Mudd, "Mudd's Women", stardate 1330.1

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[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:
> 
> http://opensource.freescale.com/pub/scm/u-boot-85xx.git

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Matthew McClintock]

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:
> > 
> > http://opensource.freescale.com/pub/scm/u-boot-85xx.git
> 
> 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

[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Markus Klotzbücher]

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.