Very Computer

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/

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/

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/

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/

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/

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/

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/

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/

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/

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/

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/

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/

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/

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/