I was examining and checking the Changelog for 2.6.15 and noticed
one commit out of the 4959 that was problematic (near line 21375):
commit 7b7abfe3dd81d659a0889f88965168f7eef8c5c6
Author: Steve French <[email protected]>
Date: Wed Nov 9 15:21:09 2005 -0800
--- end of entry ---
This change has no description and no one listed as signing it off.
Was there a 1-line description for this commit and was this
commit sign off by anyone?
Do either, the missing "signoff", or "description", constitute the
possibility that the "commit" went in "unapproved" & "unaudited"?
On a less worrisome note, 62 of the 4958 commits had no "details"
beyond (after) the 1-line description. Is it safe to say that further
"details" after the 1-line description are optional?
This is the first Changelog I've examined in this detail, so I can't
say if this is a first or one-time problem.
Thanks,
-linda
Actually, ("talking" to myself?), parsing this file a bit more,
I find many (~134) that are missing "Sign-offs".
I take it that "Sign-off"s are also "optional" on commits
and represent that the author specified under the "commit"
tag did not need a "Sign-off"?
Just trying to see if I can parse large changelogs into groups
that might be easier digest and summarize...
-linda
Linda Walsh wrote:
> I was examining and checking the Changelog for 2.6.15 and noticed
> one commit out of the 4959 that was problematic (near line 21375):
>
> commit 7b7abfe3dd81d659a0889f88965168f7eef8c5c6
> Author: Steve French <[email protected]>
> Date: Wed Nov 9 15:21:09 2005 -0800
>
> --- end of entry ---
>
> This change has no description and no one listed as signing it off.
>
> Was there a 1-line description for this commit and was this
> commit sign off by anyone?
>
> Do either, the missing "signoff", or "description", constitute the
> possibility that the "commit" went in "unapproved" & "unaudited"?
>
>
> On a less worrisome note, 62 of the 4958 commits had no "details"
> beyond (after) the 1-line description. Is it safe to say that further
> "details" after the 1-line description are optional?
>
> This is the first Changelog I've examined in this detail, so I can't
> say if this is a first or one-time problem.
>
> Thanks,
> -linda
>
> -
> 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/
On Tue, Feb 07, 2006 at 05:06:05PM -0800, Linda Walsh wrote:
> Actually, ("talking" to myself?), parsing this file a bit more,
> I find many (~134) that are missing "Sign-offs".
>
> I take it that "Sign-off"s are also "optional" on commits
> and represent that the author specified under the "commit"
> tag did not need a "Sign-off"?
>
> Just trying to see if I can parse large changelogs into groups
> that might be easier digest and summarize...
I make the count 121 (but instead of taking the Changelog I started
from the output of "git whatchanged v2.6.15 ^v2.6.14"). This was from
a total of 4959 commits, so we are scoring at 97.5%. Most of them do
appear to be an author not signing off on his own work when working in
their own git tree. Jeff Garzik seems to be an expert at this with 70
commits where he is listed as Author, but there is no signed-off-by line.
Linus is in second place with 8, but most of those were simply changing
the release in the Makefile for each "-rcN". The 2 that weren't were
Linus fixing a silly typo and reverting a previous commit, perhaps these
were deliberately not signed? Then there is a long tail. Here's the full
list with the abbreviated commit SHA1 as reported by git whatchanged.
Use "git show 000404f" (from a recent version of git) to see the commit
& diff.
Author: Adrian Bunk <[email protected]>
000404f... (from dc6f3f2...)
dc6f3f2... (from f093182...)
Author: Alan Cox <[email protected]>
11e29e2... (from 307e4dc...)
47a8659... (from fe998aa...)
9119075... (from ccd7bc2...)
Author: Albert Lee <[email protected]>
3aef523... (from c187c4b...)
9d5b130... (from 3aef523...)
c187c4b... (from 47a8659...)
Author: Andrew Morton <[email protected]>
89358f9... (from 48257c4...)
Author: Ayaz Abdulla <[email protected]>
ac9c189... (from 9789089...)
Author: Christoph Hellwig <[email protected]>
e330562... (from c2a8fad...)
Author: Dave Airlie <airlied@starflyer.(none)>
5fb4dc9... (from 23bfc1a...)
Author: James Ketrenos <[email protected]>
519a62b... (from d3f7bf4...)
af9288a... (from 6eb6edf...)
cf1b479... (from 8171537...)
d7e02ed... (from e189277...)
Author: Jaroslav Kysela <[email protected]>
b00e844... (from 63786d0...)
Author: Jeff Garzik <[email protected]>
005a5a0... (from e533825...)
0169e28... (from be15cd7...)
02eaa66... (from 828d09d...)
057ace5... (from cf48293...)
07c1da2... (from 00ac37f...)
095fec8... (from 02eaa66...)
0e5dec4... (from 54dac83...)
0f0d519... (from a7dac44...)
101ffae... (from 522479f...)
193515d... (from 0b154bb...)
2237467... (from 64f043d...)
2759c8d... (from e2e9650...)
2917953... (from f85272a...)
2a47ce0... (from 101ffae...)
2c13b7c... (from e1410f2...)
2d5a2ae... (from 63172cb...)
3b7d697... (from f51750d...)
3f19ee8... (from 644dd0c...)
422fa08... (from ffe75ef...)
47c2b67... (from ba3fe8f...)
5063019... (from be0d9b6...)
50eb800... (from ecf8b59...)
522479f... (from 47c2b67...)
6037d6b... (from c2cc87c...)
6248e64... (from 0f0d519...)
644dd0c... (from 87e807b...)
64f043d... (from 556c66d...)
67846b3... (from 643736a...)
68399bb... (from edea3ab...)
7bbaa75... (from 2d5a2ae...)
7bdd720... (from c2cd76f...)
828d09d... (from cd52d1e...)
8a70f8d... (from 05b308e...)
8b26024... (from 095fec8...)
8cee0cd... (from bb40dcb...)
972c26b... (from b194b42...)
98684a9... (from be0d9b6...)
9a68c1b... (from 8b26024...)
9f68a24... (from c6e6e66...)
a10b5aa... (from 4aefe15...)
a121349... (from bfd0072...)
a15dbeb... (from 67846b3...)
a21a84a... (from 96b88fb...)
a2c91a8... (from 2237467...)
a7dac44... (from 81cfb88...)
a939c96... (from a15dbeb...)
a9524a7... (from fbf30fb...)
ac19bff... (from 9dfb780...)
ad36d1a... (from 4ba529a...)
b095518... (from 88d7bd8...)
b2795f5... (from 2468297...)
ba3fe8f... (from bca1c4e...)
bca1c4e... (from 9a68c1b...)
be2b28e... (from a7990ba...)
c2a8fad... (from eedb9f0...)
c2cd76f... (from 75b1f2f...)
c6e6e66... (from 2c13b7c...)
c9d3913... (from 2a47ce0...)
cedc9a4... (from ed39f73...)
cf48293... (from 452503f...)
e12669e... (from 8a70f8d...)
e1410f2... (from ad36d1a...)
e2b1be5... (from c0ab424...)
e2e9650... (from 596ff2e...)
e533825... (from 6e9d6b8...)
ea182d4... (from ab80882...)
ecf8b59... (from a10b5aa...)
f7492f1... (from 51c83a9...)
fbf30fb... (from 6248e64...)
Author: Jeff Garzik <[email protected]>
0274aa2... (from 80bd6d7...)
Author: Jeff Raubitschek <[email protected]>
54dac83... (from 2ee73cc...)
Author: Jesper Juhl <[email protected]>
b4558ea... (from 7380a78...)
Author: <jketreno@io.(none)>
25b645b... (from 8232835...)
Author: John Linville <[email protected]>
6c1792f... (from dbc2309...)
Author: Komuro <[email protected]>
ab80882... (from 1d97f38...)
Author: Kyungmin Park <[email protected]>
20ba89a... (from 37b1cc3...)
Author: Ladislav Michl <[email protected]>
a637a11... (from a06d61c...)
Author: Linus Torvalds <[email protected]>
0fde7f5... (from 3beb207...)
1224b37... (from 8e31108...)
3bedff1... (from 4477914...)
5666c09... (from d2149b5...)
624f54b... (from 5d24091...)
8802684... (from 8f493d7...)
cd52d1e... (from 508862e...)
f89f594... (from 01e33b5...)
Author: Mark Lord <[email protected]>
edea3ab... (from 3d3467f...)
dcc2d1e... (from e12a1be...)
Author: Mateusz Berezecki <[email protected]>
e260836... (from 075897c...)
Author: Michal Wronski <[email protected]>
65163fd... (from 6dfca87...)
Author: Pantelis Antoniou <[email protected]>
48257c4... (from d8840ac...)
Author: Paul Mackerras <[email protected]>
a21ead3... (from df0d3ce...)
Author: Ralf Baechle <[email protected]>
15b96a4... (from 307bd28...)
2862279... (from 15b96a4...)
Author: Russell King <[email protected]>
866237e... (from e399822...)
d56c524... (from 866237e...)
e399822... (from 30c2f90...)
Author: Steve French <[email protected]>
190fdeb... (from 0ae0efa...)
7b7abfe... (from e82b3ae...)
Author: Tejun Heo <[email protected]>
537a95d... (from fecb4a0...)
Author: Thomas Gleixner <[email protected]>
03ead84... (from 182ec4e...)
f0250fd... (from 01ac742...)
Author: Trond Myklebust <[email protected]>
6fa05b1... (from ab27642...)
f134585... (from 3063d8a...)
Author: Zhu Yi <[email protected]>
a1e695a... (from ee8e365...)
Luck, Tony wrote:
> On Tue, Feb 07, 2006 at 05:06:05PM -0800, Linda Walsh wrote:
>
>> Actually, ("talking" to myself?), parsing this file a bit more,
>> I find many (~134) that are missing "Sign-offs".
>>
>> I take it that "Sign-off"s are also "optional" on commits
>> and represent that the author specified under the "commit"
>> tag did not need a "Sign-off"?
>>
> Most of them do
> appear to be an author not signing off on his own work when working in
> their own git tree. Jeff Garzik seems to be an expert at this with 70
> commits where he is listed as Author, but there is no signed-off-by line.
> Linus is in second place with 8, but most of those were simply changing
> the release in the Makefile for each "-rcN". The 2 that weren't were
> Linus fixing a silly typo and reverting a previous commit, perhaps these
> were deliberately not signed? Then there is a long tail...
I suppose I'm unclear as to why sign-offs were added to the GIT
change-log entries in the first place.
I thought Sign-offs were added to provide an "accountability" trail for
*ALL* new lines of code going into the kernel. I though it was desired
to know "Who" made or added "What" changes into the kernel to ensure
that added code could be traced to its source to protect against
infringement claims that might arise as well as verifying that changes
had been reviewed for sanity and someone wasn't unintentionally or
deliberately adding "suspect" or "insecure" code.
Given human nature, I'm guessing there isn't sufficient concern about
this issue until we've been bitten several times: hard.
Sigh.
Linda
On Wed, 8 Feb 2006, Linda Walsh wrote:
> Luck, Tony wrote:
> > On Tue, Feb 07, 2006 at 05:06:05PM -0800, Linda Walsh wrote:
> >
> >> Actually, ("talking" to myself?), parsing this file a bit more,
> >> I find many (~134) that are missing "Sign-offs".
> >>
> >> I take it that "Sign-off"s are also "optional" on commits
> >> and represent that the author specified under the "commit"
> >> tag did not need a "Sign-off"?
> >>
> > Most of them do
> > appear to be an author not signing off on his own work when working in
> > their own git tree. Jeff Garzik seems to be an expert at this with 70
> > commits where he is listed as Author, but there is no signed-off-by line.
> > Linus is in second place with 8, but most of those were simply changing
> > the release in the Makefile for each "-rcN". The 2 that weren't were
> > Linus fixing a silly typo and reverting a previous commit, perhaps these
> > were deliberately not signed? Then there is a long tail...
> I suppose I'm unclear as to why sign-offs were added to the GIT
> change-log entries in the first place.
>
> I thought Sign-offs were added to provide an "accountability" trail for
> *ALL* new lines of code going into the kernel. I though it was desired
> to know "Who" made or added "What" changes into the kernel to ensure
> that added code could be traced to its source to protect against
> infringement claims that might arise as well as verifying that changes
> had been reviewed for sanity and someone wasn't unintentionally or
> deliberately adding "suspect" or "insecure" code.
>
> Given human nature, I'm guessing there isn't sufficient concern about
> this issue until we've been bitten several times: hard.
>
> Sigh.
Linda, did you have some other point that you are trying to get to,
or is that it? There are real efforts being made, although not
perfect. That happens when people are involved.
Anyway, it feels like you are just getting to the surface/edge
of your complaint.
--
~Randy
On Wed, Feb 08, 2006 at 03:00:01PM -0800, Randy.Dunlap took 50 lines to write:
> On Wed, 8 Feb 2006, Linda Walsh wrote:
>
> > Luck, Tony wrote:
> > > On Tue, Feb 07, 2006 at 05:06:05PM -0800, Linda Walsh wrote:
> > >
> > >> Actually, ("talking" to myself?), parsing this file a bit more,
> > >> I find many (~134) that are missing "Sign-offs".
> > >>
> > >> I take it that "Sign-off"s are also "optional" on commits
> > >> and represent that the author specified under the "commit"
> > >> tag did not need a "Sign-off"?
[...]
> Linda, did you have some other point that you are trying to get to,
> or is that it? There are real efforts being made, although not
> perfect. That happens when people are involved.
> Anyway, it feels like you are just getting to the surface/edge
> of your complaint.
The way I read this thread, I thought the complaint was that she's
having difficulty writing one or more tools to process the changes
automatically. Perhaps I'm not seeing past the surface.
Kurt
--
On a paper submitted by a physicist colleague:
"This isn't right. This isn't even wrong."
-- Wolfgang Pauli
On Wed, 8 Feb 2006, Kurt Wall wrote:
> On Wed, Feb 08, 2006 at 03:00:01PM -0800, Randy.Dunlap took 50 lines to write:
> > On Wed, 8 Feb 2006, Linda Walsh wrote:
> >
> > > Luck, Tony wrote:
> > > > On Tue, Feb 07, 2006 at 05:06:05PM -0800, Linda Walsh wrote:
> > > >
> > > >> Actually, ("talking" to myself?), parsing this file a bit more,
> > > >> I find many (~134) that are missing "Sign-offs".
> > > >>
> > > >> I take it that "Sign-off"s are also "optional" on commits
> > > >> and represent that the author specified under the "commit"
> > > >> tag did not need a "Sign-off"?
>
> [...]
>
> > Linda, did you have some other point that you are trying to get to,
> > or is that it? There are real efforts being made, although not
> > perfect. That happens when people are involved.
> > Anyway, it feels like you are just getting to the surface/edge
> > of your complaint.
>
> The way I read this thread, I thought the complaint was that she's
> having difficulty writing one or more tools to process the changes
> automatically. Perhaps I'm not seeing past the surface.
You could be right, but then she has solved it (noted as
"optional" fields above). Good.
--
~Randy
Randy.Dunlap wrote:
> Linda, did you have some other point that you are trying to get to,
> or is that it? There are real efforts being made, although not
> perfect. That happens when people are involved.
>
It depends on what tools you use to verify input. How many
commits don't "compile"? There are people involved in
that effort, but that doesn't mean we accept C-syntax
errors as being inevitable does it?
If something doesn't compile, isn't it expected that the author
will fix it before it becomes part of the mainline code?
Commit meta-information can as easily be verified for basic
"syntax" (field presence). If a commit is missing basic
information, it could be bounced back to the submitter to be
fixed before being accepted into the mainline tree.
No more perfection is required than is already accepted for C-source
files: if they don't compile, fix them. There's no discussions
about people making an "effort" to have kernel releases that compile.
They either do, or don't (ignoring vagaries of untested platform,
Config options or compiler differences).
> Anyway, it feels like you are just getting to the surface/edge
> of your complaint.
>
Complaint is a bit stronger than I meant. You could take it
as a report of a new "commit" that doesn't compile correctly. That's
not usually a complaint in a development environment -- that's
part of the development, test and fix cycle.
I'm just trying to, programatically, read in the Changes file so
I can, perhaps, sort them by by some criteria. I ran into "syntax"
errors in the Change-log regarding missing fields. This is a an
_inquiry_ into what meta-information "should" be included with a commit:
What is expected? What is required? What is desired?
I'm not expecting the current version of the change log to be "fixed",
but if we have no measure or feedback regarding how well we are
adhering to *whatever* standard is "agreed" (or mandated), how can
we know if we are know if we are "there" yet?
Someday, maybe the 1-line descriptions could be complete enough for
automatic parsing & sorting so someone could look choose to look
at changes in a particular subsystem, driver or architecture. But
that level of 'semantic' validity is a bit beyond simple
"commit" meta-info syntax checking. ;-)
Linda