On 09/07/07, Linus Torvalds <[email protected]> wrote:
[snip]
The shortlog (appended) is fairly self-explanatory and the diffstat (at
the very end) also gives a fairly good picture of where the changes are.
I've always felt that these "shortlog since last -rc for a full
release" were a bit pointless.
Whoever is reading the release notes for a final 2.6.x release is not
going to be really interrested in what changed since the last -rc,
they want to know what changed since the last 2.6.(x-1) kernel. And
the people who are interrested in the changes since last -rc have
obviously been keeping track of what happened between the previous
-rc's (or else reading the last one doesn't make much sense).
The full changelog since 2.6.21 also got uploaded, but quite frankly, I
wonder if anybody uses those things? I've been uploading them for non-git
users, but I have a suspicion that any people who want that kind of
detail have long since learnt to use git, or are following the commit
mailing lists or equivalent.
I believe you are right, but it's still a nice thing to have for
archeology purposes. To be able to download kernel 2.6.(some old x)
along with its Changelog makes for a nice combined package where
people can see where this kernel is different from the previous one...
it's just a nice thing to have in the FTP archives.
I won't cry much if it dies, but on the other hand I think it's a good
thing to have archived in a plain-text form for posterity.
So this is also a heads-up that I'm considering skipping the ChangeLog
files in the future - the full release ones are so big as to not be very
easily readable (the full ChangeLog from 2.6.21 is ove ra hundred thousand
lines, and weighs in at 3.8MB for example), and you really can get much
better per-subsystem logs from git.
Anybody? Should I make just the shortlogs available instead (I don't save
those, but I post those for the later -rc's - usually the -rc1 and -rc2's
are too big for the mailing list, but they are still a lot smaller and
more readable than the *full* logs are)?
This is just my oppinion. The shortlogs are nice and readable,
archiving the shortlog-between-rc's would be nice, as for the full
logs see above.
I think what would be even better than posting full-/short-logs after
each -rc/full release, would be to post a list of who was involved in
that specific kernel release. I think that you are right that the
people who want the full details know how to use git (or else they can
get to parse the full Changelog), but what's really more interresting
is giving credit where it is due.
I'd suggest that whenever you release a new kernel you should upload
the full Changelog since last version, just so it's available. But, in
your release notes you should just list who contributed to that new
release, something like this :
juhl@dragon:~/kernel/linux-2.6$ git log v2.6.21..v2.6.22 | egrep
"^Author: " | sort | uniq -c | sort -n -r
283 Author: Linus Torvalds <[email protected]>
174 Author: David S. Miller <[email protected]>
106 Author: Kristian Høgsberg <[email protected]>
88 Author: Stephen Hemminger <[email protected]>
84 Author: Christoph Lameter <[email protected]>
82 Author: Stefan Richter <[email protected]>
79 Author: Arnaldo Carvalho de Melo <[email protected]>
78 Author: Tejun Heo <[email protected]>
78 Author: Patrick McHardy <[email protected]>
78 Author: Dmitry Torokhov <[email protected]>
...
The details are in git / the Changelog, but this lets the worls easily
see who contributed - I suspect that's a lot more interresting to the
people reading your release-mails. I could be wrong (and I probably
am) ;-)
Or do people really want the full logs, and don't use git?
git rules. It's a fantastic tool - anyone wanting the full details
should use it.
Let me know how you feel. And test the actual release out too, of course!
Running 2.6.22-rc7-g4e99325b atm :)
--
Jesper Juhl <[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]