[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Jon Loeliger]

Wolfgang,

I was wondering if either of these two commands comes
close to being a "replacement" for automatically
generating the CHANGELOG in a format that is close
to what you would like:

    git log --pretty=shortlog LABEL_2006_06_30_2020..HEAD | git shortlog
or
    git log LABEL_2006_06_30_2020..HEAD | egrep -v '^Merge|^commit'

Here, I picked LABEL_2006_06_30_2020 as an arbitrary example of
how you select the starting point of a range to delimit the
set of changes you are interested in capturing.

If either of these is close, it might be a pretty simple mod
to, say, the "git shortlog" script to make it more acceptable.

Here are some shortened example outputs from the first and second
commands, respectively.  The first batches by Author, and the
second follows a topologically correct commit history flow.

Thanks,
jdl

----------------


$ git log --pretty=shortlog LABEL_2006_06_30_2020..HEAD | git shortlog

Andy Fleming:
      Added code to support 2.6.18 PCI changes in u-boot
      Add support for eTSEC 3 & 4 on 8548 CDS
      Updated config headers to add default FDT-based booting

Bartlomiej Sieka:
      Fix problems with SanDisk Corporation Cruzer Micro USB memory stick.
      Add rudimentary handling of alternate settings of USB interfaces - to fix
      Prevent USB commands from working when USB is stopped.
      Add a fix for a buggy USB device on the FO300 board.

Detlev Zundel:
      Added interrupt handling capabilities for mpc5xxx processors.
      Added simple_strtoul(), getenv() and setenv() to the exported functions.
      Added another example showing simple interrupt interception.
      Added changelog entry for previous small commits and extended README on
      Added David Updegraff as maintainer of CRAYL1

Grant Likely:
      Fix possible uninitialized variable compiler warning.

----------------

$ git log LABEL_2006_06_30_2020..HEAD | egrep -v '^Merge|^commit'

Author: Jon Loeliger <jdl@freescale.com>
Date:   Thu Oct 12 11:29:33 2006 -0500

    Merge branch 'master' of http://www.denx.de/git/u-boot

Author: Jon Loeliger <jdl@freescale.com>
Date:   Thu Oct 12 10:42:36 2006 -0500

    Remove unneeded include files and local variable.

    Signed-off-by: Jon Loeliger <jdl@freescale.com>

Author: Grant Likely <grant.likely@secretlab.ca>
Date:   Tue Oct 10 00:23:32 2006 -0600

    Fix possible uninitialized variable compiler warning.

    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>

Author: Wolfgang Denk <wd@pollux.denx.de>
Date:   Thu Oct 12 11:43:47 2006 +0200

    Fix spelling; minor code cleanup.

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Wolfgang Denk]

Dear Jon,

in message <E1GYBd8-0001Gp-Kd@jdl.com> you wrote:
> 
> I was wondering if either of these two commands comes
> close to being a "replacement" for automatically
> generating the CHANGELOG in a format that is close
> to what you would like:

Thanks a lot for the suggestions.

> If either of these is close, it might be a pretty simple mod
> to, say, the "git shortlog" script to make it more acceptable.

A variation of (2) is perfectly fine with me:

	git log | egrep -v '^Merge'

[I think the commit ID should be included.]


So since I seem to be the only person on this  planet  who  likes  to
have this CHANGELOG file, and it has caused so much trouble already I
suggest the following procedure:

(1) I will freeze the current setup and probably even release  it  as
    U-Boot 1.1.5 (mostly to feed all those FTP-only downloaders).

(2) rename CHANGELOG into CHANGELOG.OLD, and start  a  new  CHANGELOG
    which  gets  automatically generated using the command above or a
    variation thereof.

    Note: nobody needs to take care of this file. It is purely for my
    own private needs, and I will manage it on my own. Everybody else
    can just ignore the existence of this file.

(3) I will merge your and Matthew McClintock's 85xx  which  (from  my
    point  of  view)  suffer  mostly  just from the missing CHANGELOG
    entries.

(4) Remaining issues like coding  style  cleanup  etc.  can  be  then
    sorted out in the merged trees. If I should see bigger problems I
    will create branches that can be used as reference.

Is this acceptable to you and everybody else?

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
Defaults are wonderful, just like fire.
                  - Larry Wall in <1996Mar6.004121.27890@netlabs.com>

[U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jon,

[snip]

> (1) I will freeze the current setup and probably even release  it  as
>     U-Boot 1.1.5 (mostly to feed all those FTP-only downloaders).
> 
> (2) rename CHANGELOG into CHANGELOG.OLD, and start  a  new  CHANGELOG
>     which  gets  automatically generated using the command above or a
>     variation thereof.
> 
>     Note: nobody needs to take care of this file. It is purely for my
>     own private needs, and I will manage it on my own. Everybody else
>     can just ignore the existence of this file.

I'm sure other people use it, I read it for entertainment occasionally. 
  For instance, it is useful to sort the local commit noise from the 
"official" noise, following what is going on in the main tree.

> (3) I will merge your and Matthew McClintock's 85xx  which  (from  my
>     point  of  view)  suffer  mostly  just from the missing CHANGELOG
>     entries.

Excellent!  My git repository is a hodgepodge based off the official one 
with Jon's changes pulled in (which presumably are the same as 
Matthew's, but I haven't verified that...).  When Wolfgang pulls the 
changes into the main repository it will enable me to get my house 
cleaned up and submit my changes as well.

I'm loving git's abilities to track and merge repositories, but I'm 
developing "at risk" since my world is neither WD nor JDL and I'm 
counting on Wolfgang to do this merge to make my world OK again.  When 
this happens, I'll be able to submit some patches to create cmd_of.c and 
improve ft_build.c and vsprintf.c (maybe, see below).

> (4) Remaining issues like coding  style  cleanup  etc.  can  be  then
>     sorted out in the merged trees. If I should see bigger problems I
>     will create branches that can be used as reference.
> 
> Is this acceptable to you and everybody else?

You bet!

> Best regards,
> Wolfgang Denk

OK, now for the rest of the subject line (sorry about that, but they are 
all intertwined via our respective git repositories).

My git repository:
<http://www.cideas.us/git>

Project for this discussion:
<http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary>

cmd_of.c, ft_build.c
--------------------
I've created a "of" command that allows you to dump all or part of a 
flattened tree.  To make the command more usable, I enhanced ft_build.c 
to do partial dumps.

The "of" command syntax is:
   of <address> [<node or property>]
If you specify just the address, it dumps the whole tree (gaak!).
If you specify a property (e.g. /model) it prints out just that property.
If you specify a node (e.g. /cpus) it prints out the whole node, 
including all nested nodes.  Specifying "/" dumps the whole tree.

vsprintf.c, long long print problem
-----------------------------------
vsprintf.c was enhanced fairly recently to print 64 bit quantities using 
the "q" modifier.  Pantelis Antoniou (or Vitaly) used the modifier 
"%llx" to print 64 bit property values, which didn't work with 
vsprintf.c, so I enhanced vsprintf.c to accept "ll" and change it 
internally to "q" (I also changed ft_build.c to print as "0x%016llx" as 
well to print the leading zeros).  All was well with the world, until I 
noticed that the interrupt node "reg" was printing "0x00000000f8200004" 
when it should have been printing "0xf8200000f8200004":
     interrupt-controller at f8200000 {
         linux,phandle = <0xf8200000>;
         #address-cells = <0x00000000>;
         #interrupt-cells = <0x00000002>;
         interrupt-controller;
         reg = <0x00000000f8200004>;
         built-in;
         device_type = "pci-pic";
     };

I have *NOT* been able to figure out why long long printing is *NOT* 
working correctly.  It does *NOT* work correctly for the "%q" version 
either.  My current theory is that varargs isn't working correctly for 
long long, but I have not chased down that path (yet).

At the moment, my copy of ft_build.c prints 8 byte entries as a double 
word "<%08x %08x>" rather than using 64 bit prints.

gvb

[U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem

[Wolfgang Denk]

Hello,

in message <452F9380.3010505@smiths-aerospace.com> you wrote:
> 
> I'm sure other people use it, I read it for entertainment occasionally. 

:-) Welcome #2!

>   For instance, it is useful to sort the local commit noise from the 
> "official" noise, following what is going on in the main tree.

Indeed. We will lose this filtering when using a  git  log  generated
file.

> > Is this acceptable to you and everybody else?
> 
> You bet!

Just for the record: I have a few very busy days in front  of  me.  I
miught  be  able to do the first steps on Sunday evening / night, but
then I'll probably not be able to do anything again before Wednesday.
So please be patient, if I don't reply immediately this does not mean
I ignore any messages.

> My git repository:
> <http://www.cideas.us/git>
> 
> Project for this discussion:
> <http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary>
> 
> cmd_of.c, ft_build.c

I understand this might need to be cleaned up after we  merged  Jon's
and  Matthew's  trees, so I will wait until then, OK? Will you please
trigger me again then?

> vsprintf.c, long long print problem
...
> I have *NOT* been able to figure out why long long printing is *NOT* 
> working correctly.  It does *NOT* work correctly for the "%q" version 
> either.  My current theory is that varargs isn't working correctly for 
> long long, but I have not chased down that path (yet).

Did you check the assembler code? Which exact toolchain are you using?


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
You are in a maze of UUCP connections, all alike.

[U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem

[Jerry Van Baren]

Wolfgang Denk wrote:
> Hello,
> 
> in message <452F9380.3010505@smiths-aerospace.com> you wrote:
>> I'm sure other people use it, I read it for entertainment occasionally. 
> 
> :-) Welcome #2!
> 
>>   For instance, it is useful to sort the local commit noise from the 
>> "official" noise, following what is going on in the main tree.
> 
> Indeed. We will lose this filtering when using a  git  log  generated
> file.
> 
>>> Is this acceptable to you and everybody else?
>> You bet!
> 
> Just for the record: I have a few very busy days in front  of  me.  I
> miught  be  able to do the first steps on Sunday evening / night, but
> then I'll probably not be able to do anything again before Wednesday.
> So please be patient, if I don't reply immediately this does not mean
> I ignore any messages.

Yes, I understand.  Actually, the exclamation marks in my original reply 
were for joy that it was happening so soon, I was afraid I would be in 
limbo for a lot longer.

>> My git repository:
>> <http://www.cideas.us/git>
>>
>> Project for this discussion:
>> <http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary>
>>
>> cmd_of.c, ft_build.c
> 
> I understand this might need to be cleaned up after we  merged  Jon's
> and  Matthew's  trees, so I will wait until then, OK? Will you please
> trigger me again then?

Yes, that was just for reference in case someone wanted to browse my 
changes.  I'll submit a proper patch when Jon's stuff is in the main 
repo and I can do a clean patch that doesn't conflict with Jon's work 
(including clean CHANGELOG type comments ;-).

>> vsprintf.c, long long print problem
> ...
>> I have *NOT* been able to figure out why long long printing is *NOT* 
>> working correctly.  It does *NOT* work correctly for the "%q" version 
>> either.  My current theory is that varargs isn't working correctly for 
>> long long, but I have not chased down that path (yet).
> 
> Did you check the assembler code? Which exact toolchain are you using?

a) No.  I'll do that.
b) ELDK4.0 with the 82xx PowerPC target.

> Best regards,
> 
> Wolfgang Denk

Thanks,
gvb

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Jon Loeliger]

So, like, the other day Wolfgang Denk mumbled:
> Dear Jon,
> 
> Thanks a lot for the suggestions.

Most welcome.

> > If either of these is close, it might be a pretty simple mod
> > to, say, the "git shortlog" script to make it more acceptable.
> 
> A variation of (2) is perfectly fine with me:

Excellent.

> So since I seem to be the only person on this  planet  who  likes  to
> have this CHANGELOG file, and it has caused so much trouble already I
> suggest the following procedure:
>
> ...
> 
> Is this acceptable to you and everybody else?

This is really good!  Thanks!

Having the baseline 85xx and FDT parts from Matthew will
make much of this vastly easier for the 86xx changes!

Thank you.

jdl

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Jon Loeliger]

So, like, the other day Wolfgang Denk mumbled:

> A variation of (2) is perfectly fine with me:
> 
> 	git log | egrep -v '^Merge'
> 
> [I think the commit ID should be included.]

And just to be the first to point out my own lameness:

    git log --no-merges

:-)

jdl

[U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem

[Jon Loeliger]

So, like, the other day Jerry Van Baren mumbled:
> 
> OK, now for the rest of the subject line (sorry about that, but they are 
> all intertwined via our respective git repositories).
> 
> My git repository:
> <http://www.cideas.us/git>
> 
> Project for this discussion:
> <http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary>

Cool.  I'll try and track down some time to look at them!

> cmd_of.c, ft_build.c
> --------------------
> I've created a "of" command that allows you to dump all or part of a 
> flattened tree.  To make the command more usable, I enhanced ft_build.c 
> to do partial dumps.

Thank you.  You have saved me/Matthew from doing this. :-)

> At the moment, my copy of ft_build.c prints 8 byte entries as a double 
> word "<%08x %08x>" rather than using 64 bit prints.

Hmmm... That might be an OK stop-gap, but I don't
think we should count on that long term, of course.

> gvb

Thanks,
jdl

[U-Boot-Users] CHANGELOG w/ status update: cmd_of.c, ft_build.c, vsprintf.c, long long print problem

[Jerry Van Baren]

Jon Loeliger wrote:
> So, like, the other day Jerry Van Baren mumbled:
>> OK, now for the rest of the subject line (sorry about that, but they are 
>> all intertwined via our respective git repositories).
>>
>> My git repository:
>> <http://www.cideas.us/git>
>>
>> Project for this discussion:
>> <http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary>
> 
> Cool.  I'll try and track down some time to look at them!
> 
>> cmd_of.c, ft_build.c
>> --------------------
>> I've created a "of" command that allows you to dump all or part of a 
>> flattened tree.  To make the command more usable, I enhanced ft_build.c 
>> to do partial dumps.
> 
> Thank you.  You have saved me/Matthew from doing this. :-)

Yerwelcome.  Standing on the shoulders of giants and all that...

One thing I didn't "fix" is that the dump is missing the leading "/" for 
the root node, it prints
=> of 300000
  {
     model = "PQ2FADS";
     compatible = "MPC8260ADS";
     #address-cells = <00000001>;
     #size-cells = <00000001>;
     linux,phandle = <00000100>;
     :
     :
     };

instead of
=> of 300000
/ {
^-- missing "/"
     model = "PQ2FADS";
     compatible = "MPC8260ADS";
     #address-cells = <00000001>;
     #size-cells = <00000001>;
     linux,phandle = <00000100>;
     :
     :
     };

This happens because the "/" is put on the end of the old node path when 
concatenating the new node, rather than putting in on the start of the 
new node when a new node is found (this is a better approach except for 
the root node).  Since the first node has no "old" node to concatenate 
the "/" to, it never gets added.

I presume this is an error and will fix it.

>> At the moment, my copy of ft_build.c prints 8 byte entries as a double 
>> word "<%08x %08x>" rather than using 64 bit prints.
> 
> Hmmm... That might be an OK stop-gap, but I don't
> think we should count on that long term, of course.
> 
>> gvb
> 
> Thanks,
> jdl

gvb

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Timur Tabi]

Wolfgang Denk wrote:

> Is this acceptable to you and everybody else?

Sounds great to me, but I submitted a patch or two a few weeks ago with changes to CHANGELOG.  Will I need to resubmit those patches?  I think by the time you get around to applying those patches, CHANGELOG will be long gone and the patch won't apply.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Wolfgang Denk]

In message <452FB1DD.1040109@freescale.com> you wrote:
> 
> Sounds great to me, but I submitted a patch or two a few weeks ago with changes to CHANGELOG.  Will I need to resubmit those patches?  I think by the time you get around to applying those patches, CHANGELOG will be long gone and the patch won't apply.

No, you doon't have  to  resubmit.  I've  always  been  dealing  with
conflicts  with  the  CHANGELOG  file, and will continue to do so for
older patches.

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
Misquotation is, in fact, the pride and privilege of the  learned.  A
widely-read  man  never  quotes  accurately,  for  the rather obvious
reason that he has read too widely.
                - Hesketh Pearson _Common Misquotations_ introduction

[U-Boot-Users] Proposed CHANGELOG Generation Helpers

[Grant Likely]

On 10/13/06, Wolfgang Denk <wd@denx.de> wrote:

> So since I seem to be the only person on this  planet  who  likes  to
> have this CHANGELOG file, and it has caused so much trouble already I
> suggest the following procedure:
<snip> ...

Sounds good to me

g.


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