Changelogs on kernel.org

Changelogs on kernel.org

Post by Ian Molto » Mon, 13 May 2002 09:10:04



Hi.

I dont know who to write to about this, but the changelogs for
2.4.19-pre on kernel.org are COMPLETELY illegible.

Can we 'tweak' them so that instead of:


        Fix meye driver request_irq bug.


        Enable the meye driver to get parameters on the kernel command line.


        [PATCH] add __LINE__ to out_of_line_bug()


        [PATCH] PATCH: some configure.help updates


        [PATCH] PATCH: more configure.help


        [PATCH] PATCH: More configure.help


        [PATCH] PATCH: more Configure.help


        [PATCH] PATCH: maintainers update


        [PATCH] PATCH: make cpu names clearer for new VIA

We get something nice like:


   Fix meye driver request_irq bug.
   Enable the meye driver to get parameters on the kernel command line.


   [PATCH] add __LINE__ to out_of_line_bug()


   [PATCH] PATCH: some configure.help updates
   [PATCH] PATCH: more configure.help
   ... above repeated 2 times
   [PATCH] PATCH: maintainers update
   [PATCH] PATCH: make cpu names clearer for new VIA

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Diego Callej » Mon, 13 May 2002 09:50:10


On Sun, 12 May 2002 01:07:09 +0100

> Hi.

> I dont know who to write to about this, but the changelogs for
> 2.4.19-pre on kernel.org are COMPLETELY illegible.

> Can we 'tweak' them so that instead of:


>    Fix meye driver request_irq bug.

Well, why not having the date -02/04/17 in that case-?
What I'd really like to know is "1.383.12.1". I suposse it's bitkeeper info.
?It's really useful?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by john sle » Mon, 13 May 2002 10:10:07



> I dont know who to write to about this, but the changelogs for
> 2.4.19-pre on kernel.org are COMPLETELY illegible.

you seem to be the only one publicly complaining.  go write a procmail
recipe to fix them up.

j.

--
R N G G   "Well, there it goes again... And we just sit
 I G G G   here without opposable thumbs." -- gary larson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by john sle » Mon, 13 May 2002 10:20:09




> > I dont know who to write to about this, but the changelogs for
> > 2.4.19-pre on kernel.org are COMPLETELY illegible.

> you seem to be the only one publicly complaining.  go write a procmail
> recipe to fix them up.

duh, that was a bit of a thinko.  of course you could apply the same to
a shell script.  :-)

i suspect that some people sufficiently "one with BK" might want the
version-number-looking-things for each item in the changelog, not just
per person.

j.

--
R N G G   "Well, there it goes again... And we just sit
 I G G G   here without opposable thumbs." -- gary larson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Brian C. Huffma » Mon, 13 May 2002 14:20:07


Generally the defense that "no one else is saying anything" is not a
good one - especially b/c it opens up a huge space for others to agree
with the original argument.  And yes, they are illegible.  

In fact, I believe that when things originally moved to BK, there was
some discussion that although it was a step in the right direction, it
needed to be cleaned up a little bit.

-Brian



> > I dont know who to write to about this, but the changelogs for
> > 2.4.19-pre on kernel.org are COMPLETELY illegible.

> you seem to be the only one publicly complaining.  go write a procmail
> recipe to fix them up.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Changelogs on kernel.org

Post by Trever L. Adam » Mon, 13 May 2002 18:20:08




> > I dont know who to write to about this, but the changelogs for
> > 2.4.19-pre on kernel.org are COMPLETELY illegible.

> you seem to be the only one publicly complaining.  go write a procmail
> recipe to fix them up.

> j.

It seems to me that there is one positive change that could be made.
The directory of the change should be named (since multiple files could
be affected, directories are probably fewer in number).

Trever

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Johnny Mnemoni » Tue, 14 May 2002 00:00:11



Quote:> Generally the defense that "no one else is saying anything" is not a
> good one - especially b/c it opens up a huge space for others to agree
> with the original argument.  And yes, they are illegible.

I agree. If developers need that changelog style it's fine, but on kernel.org
homepage there should the old changelog format, so everyone can read it.
The best changelog i've ever seen is the one used around ~2.4.9 release

 - changedescription                         (author)

Regards

--
Johnny
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Linus Torval » Tue, 14 May 2002 05:10:12




Quote:

>I dont know who to write to about this, but the changelogs for
>2.4.19-pre on kernel.org are COMPLETELY illegible.

Hmm..

You're definitely right about the BK version numbers, since those are
meaningless anyway (they are only meaningful within one BK tree, and
they change over time when you merge different trees together.

The 2.4.x changelogs seem to be done with my "release" scripts, but
additionally they don't have the same kind of detailed information that
the 2.5.x kernels have, and yes, the result is fairly ugly.

What are peoples opinion about the "full" changelog format that v2.5.x
kernels have? Should we sort that too by author?

Perl is the obvious choice for doing transformations like these.  Is
anybody willing to write a perl script that does the "sort by author"
thing?

I'll remove the date/BK ID thing, so that my unsorted changelogs would
look like the appended thing.  But yes, sorting (and merging) by author
would probably be a good thing. (My BK changelog scripts can also add
markers around the actual log message, to make parsing easier).

                Linus

-----

Summary of changes from v2.5.13 to v2.5.14
============================================


        A bunch of fixes.


        Pmac updates


        Some more small fixes.


        [PATCH] 2.5.13: vmalloc link failure

        The following patch fixes this, and also fixes the similar problem in
        scsi_debug.c:


        [PATCH] in_ntoa link failure

        Nothing serious. Whoever it was that did that global replacemissed a
        spot is all...


        [PATCH] change_floppy() fix

        Needed both in 2.4 and 2.5
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Jeff Garzi » Tue, 14 May 2002 05:30:16



>The 2.4.x changelogs seem to be done with my "release" scripts, but
>additionally they don't have the same kind of detailed information that
>the 2.5.x kernels have, and yes, the result is fairly ugly.

>What are peoples opinion about the "full" changelog format that v2.5.x
>kernels have? Should we sort that too by author?

Sorting might help a tiny bit...

I thought about this, when I saw the 2.4.x changelogs.  Typical GNU
projects seem to have a pretty decent system going -- there is a
detailed ChangeLog, and an abbreviated high level summary NEWS, for each
release.

So IMO a good solution would not be to change the format of the BK
changelogs, but to supplement them with the type of summary that looks
like the "old Linus" changelogs, i.e. a summary generated by a human:

    Martin Dalecki - IDE updates
    Al Viro - VFS updates
    Andi Kleen - x86-64 update
    ...

The central complaint about BK changelogs seems to be that they are too
verbose for a quick scan of what a new kernel version contains.  (while
at the same time lauding the additional information BK provides over the
old changelogs)

Marcelo gave it a good shot, by (it appears) generating a summary by
taking the first line of each cset.  The better solution would be a
human-generated NEWS file.

    Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Matthew D. Pitt » Tue, 14 May 2002 05:30:20


Linus,

It would help if the some of the people that used BK would bother to be more
descriptive about the stuff they send.

I will have some patches for 2.5.x from my personal stash as soon as i get
the bugs worked out of them...

Matthew D. Pitts.

----- Original Message -----


Sent: Sunday, May 12, 2002 4:06 PM
Subject: Re: Changelogs on kernel.org



> >I dont know who to write to about this, but the changelogs for
> >2.4.19-pre on kernel.org are COMPLETELY illegible.

> Hmm..

> You're definitely right about the BK version numbers, since those are
> meaningless anyway (they are only meaningful within one BK tree, and
> they change over time when you merge different trees together.

> The 2.4.x changelogs seem to be done with my "release" scripts, but
> additionally they don't have the same kind of detailed information that
> the 2.5.x kernels have, and yes, the result is fairly ugly.

> What are peoples opinion about the "full" changelog format that v2.5.x
> kernels have? Should we sort that too by author?

> Perl is the obvious choice for doing transformations like these.  Is
> anybody willing to write a perl script that does the "sort by author"
> thing?

> I'll remove the date/BK ID thing, so that my unsorted changelogs would
> look like the appended thing.  But yes, sorting (and merging) by author
> would probably be a good thing. (My BK changelog scripts can also add
> markers around the actual log message, to make parsing easier).

> Linus

> -----

> Summary of changes from v2.5.13 to v2.5.14
> ============================================


>         A bunch of fixes.


>         Pmac updates


>         Some more small fixes.


>         [PATCH] 2.5.13: vmalloc link failure

>         The following patch fixes this, and also fixes the similar problem
in
>         scsi_debug.c:


>         [PATCH] in_ntoa link failure

>         Nothing serious. Whoever it was that did that global replacemissed
a
>         spot is all...


>         [PATCH] change_floppy() fix

>         Needed both in 2.4 and 2.5
> ...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Changelogs on kernel.org

Post by Dr. David Alan Gilber » Tue, 14 May 2002 05:40:07



<snip>

Quote:> What are peoples opinion about the "full" changelog format that v2.5.x
> kernels have? Should we sort that too by author?

I used to read the hand written changelogs, they only used to be a half
page or so; neatly summerising stuff into one line; I can't be bothered
with the full changelogs  - they are obviously useful; but the hand
written half pages are still a lot easier at a quick glance to see if
there is anything that affects you.

Perhaps insisting that each check in message includes a single line (sub
60 chars) description; could turn those into description : name and
remove dupes?

Dave
 ---------------- Have a happy GNU millennium! ----------------------  
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \

 \ _________________________|_____ http://www.treblig.org   |_______/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Florian Weime » Tue, 14 May 2002 06:20:17



> Perl is the obvious choice for doing transformations like these.  Is
> anybody willing to write a perl script that does the "sort by author"
> thing?

#!/usr/bin/perl -w
# Reformat 2.4 ChangeLog

use strict;

my %authors = ();
my $current;

while (<>) {
    chomp;
    if (/^</) {
        if (exists $authors{$_}) {
            $current = $authors{$_};
        } else {
            $current = $authors{$_} = [];
        }
    } else {
        die "illegal format" unless defined $current;

    }

Quote:}

my $author;
foreach $author (sort keys %authors) {
    print "$author\n";

    # Add empty line before next author.    
    s/\n*$/\n\n/;
    print;

Quote:}

For your example, the result is:


        A bunch of fixes.

        Pmac updates

        Some more small fixes.


        [PATCH] 2.5.13: vmalloc link failure

        The following patch fixes this, and also fixes the similar problem in
        scsi_debug.c:


        [PATCH] in_ntoa link failure

        Nothing serious. Whoever it was that did that global replacemissed a
        spot is all...


        [PATCH] change_floppy() fix

        Needed both in 2.4 and 2.5

IMHO, it doesn't make much sense.

--

University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Marcus Alane » Tue, 14 May 2002 06:50:10




>> Perl is the obvious choice for doing transformations like these.  Is
>> anybody willing to write a perl script that does the "sort by author"
>> thing?

[snip]
Basically the same, this treats each patch separately:

#!/usr/bin/perl

use strict;

my %people = ();
my $addr = "";

sub append_item() {
        if (!$addr) { return; }



Quote:}

while (<>) {
        # Match address
        if (/^<(.+)>/) {
                # Add old item (if any) before beginning new
                append_item();
                $addr = $1;
        } elsif ($addr) {
                # Add line to patch

        } else {
                # Header information
                print
        }

Quote:}

sub print_items($) {

        # Vain attempt to sort patches from one address


                # Item separator
                print "        --------------------------------------------------------------\n";

        }

Quote:}

append_item();
foreach $addr (sort keys %people) {
        print "<$addr>\n";
        print_items($addr);
        print "\n";

Quote:}

Output:

Summary of changes from v2.5.14 to v2.5.15
============================================


        --------------------------------------------------------------
        - remove spurious spaces and tabs at end of lines
        - make sure if, while, for, switch has a space before the opening '('
        - make sure no line has more than 80 chars
        - move initializations to the declaration line where possible
        - bitwise, logical and arithmetic operators have spaces before and after,
          improving readability of complex expressions
        - remove uneeded () in returns
        - other minor cleanups


        --------------------------------------------------------------
        net/ipv4/arp.c:
        - htons cleanups
        - remove duplicated code
        - apply CodingStyle

...
...

        --------------------------------------------------------------
        [PATCH] capabilities for mtrr driver.

        --------------------------------------------------------------
        [PATCH] region handling cleanup

        Done by William Stinson.
        Adds error handling to request_region() calls,
        and converts some old check_region() calls too.

        --------------------------------------------------------------
        [PATCH] region handling cleanup

        Done by William Stinson.
        Adds error handling to request_region() calls,
        and converts some old check_region() calls too.
...
...

--
Marcus Alanen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Changelogs on kernel.org

Post by Ian Molto » Tue, 14 May 2002 06:50:12


On Sun, 12 May 2002 23:17:23 +0200


> IMHO, it doesn't make much sense.

pull out the whitespace and put a bullet point in front of each entry.

Hm.

Geez, Im starting to sound like management... All I need now is a
whiteboard and some indellible non-indellible marker pens :-)

I really dont care that much. I just like to read changelogs, not decode
them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Changelogs on kernel.org

I try to avoid it as much as possible - it's actually more work for me,
and about 50% of the BK patches I get don't even apply, because the person
who sent them to me didn't send the whole series (ie left out some patch
he didn't like or something like that).

I much prefer a bk pull, if the tree I pull from is clean (ie it doesn't
have random crud in it, and it contains changsets from just one project).

Some people actually use BK but then send me regular patches anyway,
because they find that easier than setting up an exported BK tree and
being careful about cleanliness. I don't much care one way or the other:
regular email patches are easy for me to integrate, so it's really up to
you.

[ Personal opinion alert! No impact on patch acceptance, as long as
  enough changelog information exists _somewhere_ ]

I personally like good changelog comments, and I find per-file comments to
be a mistake.

I have a few simple reasons for this:

 - most changes are related, and per-file comments tend to just repeat.

   In fact, for patches, I just repeat the Subject: line in the per-file
   comments, so that they have just enough context to get the big picture.

 - if your changes _aren't_ related, you should have done multiple
   changesets in the first place. Rince and repeat as necessary.

 - the per-file comments don't show up in many of the standard changelogs
   (not mine, not in "bk changes" etc), so the per-changeset comment
   should be "sufficient" in many ways anyway.

But to each his own.

[ End personal opinion ]

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Large disks possible?

3. redhat 9 kernel diff from kernel.org kernel?

4. Netzzugriff ├╝ber Router

5. Problem with 2.4.18 kernel downloaded from kernel.org

6. olvwm visual desktop and xfilemanager custom manual; Dtop!

7. Kernel list archive? Changelog?

8. Motorola Atlas Motherboard

9. kernel 2.2.10 changelog?

10. Kernel changelogs?

11. Kernel ChangeLog

12. patch-2.4.21-rc4-ac1.bz2 on kernel.org is really patch-2.4.21-rc2-ac3?

13. ALERTE: VIRUS DETECTE DANS UN MESSAGE ENVOYE PAR linux-kernel-owner@vger.kernel.org