* Git commit process question.
@ 2019-04-01 22:33 akuster808
2019-04-01 23:02 ` Richard Purdie
0 siblings, 1 reply; 55+ messages in thread
From: akuster808 @ 2019-04-01 22:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
Hello,
I have noticed a large number of git commits with no header information
being accepted.
Are we still following:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
regards,
Armin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-01 22:33 Git commit process question akuster808
@ 2019-04-01 23:02 ` Richard Purdie
0 siblings, 0 replies; 55+ messages in thread
From: Richard Purdie @ 2019-04-01 23:02 UTC (permalink / raw)
To: akuster808, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> Hello,
>
> I have noticed a large number of git commits with no header
> information being accepted.
Can you be more specific about what "no header information" means? You
mean a shortlog and no full log message?
Cheers,
Richard
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-01 23:02 ` Richard Purdie
0 siblings, 0 replies; 55+ messages in thread
From: Richard Purdie @ 2019-04-01 23:02 UTC (permalink / raw)
To: akuster808, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> Hello,
>
> I have noticed a large number of git commits with no header
> information being accepted.
Can you be more specific about what "no header information" means? You
mean a shortlog and no full log message?
Cheers,
Richard
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-01 23:02 ` Richard Purdie
(?)
@ 2019-04-01 23:20 ` akuster808
-1 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-01 23:20 UTC (permalink / raw)
To: Richard Purdie, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On 4/1/19 4:02 PM, Richard Purdie wrote:
> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>> Hello,
>>
>> I have noticed a large number of git commits with no header
>> information being accepted.
> Can you be more specific about what "no header information" means? You
> mean a shortlog and no full log message?
Commits with just a "subject" and signoff. No additional information
We tend to reference back to how the kernel does things.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
These two sections in particular.
2) Describe your changes
Describe your problem. Whether your patch is a one-line bug fix or 5000
lines of a new feature, there must be an underlying problem that
motivated you to do this work. Convince the reviewer that there is a
problem worth fixing and that it makes sense for them to read past the
first paragraph.
along with this section.
14) The canonical patch format
This section describes how the patch itself should be formatted. Note
that, if you have your patches stored in a |git| repository, proper
patch formatting can be had with |git format-patch|. The tools cannot
create the necessary text, though, so read the instructions below anyway.
The canonical patch subject line is:
Subject: [PATCH 001/123] subsystem: summary phrase
The canonical patch message body contains the following:
* A |from| line specifying the patch author, followed by an empty
line (only needed if the person sending the patch is not the
author).
* The body of the explanation, line wrapped at 75 columns, which
will be copied to the permanent changelog to describe this patch.
* An empty line.
* The |Signed-off-by:| lines, described above, which will also go
in the changelog.
* A marker line containing simply |---|.
* Any additional comments not suitable for the changelog.
* The actual patch (|diff| output).
- Armin
>
> Cheers,
>
> Richard
>
[-- Attachment #2: Type: text/html, Size: 3992 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-01 23:20 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-01 23:20 UTC (permalink / raw)
To: Richard Purdie, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On 4/1/19 4:02 PM, Richard Purdie wrote:
> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>> Hello,
>>
>> I have noticed a large number of git commits with no header
>> information being accepted.
> Can you be more specific about what "no header information" means? You
> mean a shortlog and no full log message?
Commits with just a "subject" and signoff. No additional information
We tend to reference back to how the kernel does things.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
These two sections in particular.
2) Describe your changes
Describe your problem. Whether your patch is a one-line bug fix or 5000
lines of a new feature, there must be an underlying problem that
motivated you to do this work. Convince the reviewer that there is a
problem worth fixing and that it makes sense for them to read past the
first paragraph.
along with this section.
14) The canonical patch format
This section describes how the patch itself should be formatted. Note
that, if you have your patches stored in a |git| repository, proper
patch formatting can be had with |git format-patch|. The tools cannot
create the necessary text, though, so read the instructions below anyway.
The canonical patch subject line is:
Subject: [PATCH 001/123] subsystem: summary phrase
The canonical patch message body contains the following:
* A |from| line specifying the patch author, followed by an empty
line (only needed if the person sending the patch is not the
author).
* The body of the explanation, line wrapped at 75 columns, which
will be copied to the permanent changelog to describe this patch.
* An empty line.
* The |Signed-off-by:| lines, described above, which will also go
in the changelog.
* A marker line containing simply |---|.
* Any additional comments not suitable for the changelog.
* The actual patch (|diff| output).
- Armin
>
> Cheers,
>
> Richard
>
[-- Attachment #2: Type: text/html, Size: 3992 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-01 23:20 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-01 23:20 UTC (permalink / raw)
To: Richard Purdie, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
On 4/1/19 4:02 PM, Richard Purdie wrote:
> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>> Hello,
>>
>> I have noticed a large number of git commits with no header
>> information being accepted.
> Can you be more specific about what "no header information" means? You
> mean a shortlog and no full log message?
Commits with just a "subject" and signoff. No additional information
We tend to reference back to how the kernel does things.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
These two sections in particular.
2) Describe your changes
Describe your problem. Whether your patch is a one-line bug fix or 5000
lines of a new feature, there must be an underlying problem that
motivated you to do this work. Convince the reviewer that there is a
problem worth fixing and that it makes sense for them to read past the
first paragraph.
along with this section.
14) The canonical patch format
This section describes how the patch itself should be formatted. Note
that, if you have your patches stored in a |git| repository, proper
patch formatting can be had with |git format-patch|. The tools cannot
create the necessary text, though, so read the instructions below anyway.
The canonical patch subject line is:
Subject: [PATCH 001/123] subsystem: summary phrase
The canonical patch message body contains the following:
* A |from| line specifying the patch author, followed by an empty
line (only needed if the person sending the patch is not the
author).
* The body of the explanation, line wrapped at 75 columns, which
will be copied to the permanent changelog to describe this patch.
* An empty line.
* The |Signed-off-by:| lines, described above, which will also go
in the changelog.
* A marker line containing simply |---|.
* Any additional comments not suitable for the changelog.
* The actual patch (|diff| output).
- Armin
>
> Cheers,
>
> Richard
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-01 23:20 ` akuster808
@ 2019-04-01 23:41 ` Mark Hatle
-1 siblings, 0 replies; 55+ messages in thread
From: Mark Hatle @ 2019-04-01 23:41 UTC (permalink / raw)
To: akuster808, Richard Purdie,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
On 4/1/19 6:20 PM, akuster808 wrote:
>
>
> On 4/1/19 4:02 PM, Richard Purdie wrote:
>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>> Hello,
>>>
>>> I have noticed a large number of git commits with no header
>>> information being accepted.
>> Can you be more specific about what "no header information" means? You
>> mean a shortlog and no full log message?
> Commits with just a "subject" and signoff. No additional information
If you can convey the reason for the change in just the subject, that is
acceptable.. but there is -always- supposed to be a signed-off-by line according
to our guidelines.
So if you see this, I think we need to step back and figure out where and why
it's happening and get it resolved in the future.
(Places I've seen in the past were one-off mistakes and clearly that -- so it
wasn't anything that we needed to work on a correction.)
--Mark
> We tend to reference back to how the kernel does things.
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> These two sections in particular.
>
>
> 2) Describe your changes
>
> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> a new feature, there must be an underlying problem that motivated you to do this
> work. Convince the reviewer that there is a problem worth fixing and that it
> makes sense for them to read past the first paragraph.
>
>
> along with this section.
>
>
> 14) The canonical patch format
>
> This section describes how the patch itself should be formatted. Note that, if
> you have your patches stored in a |git| repository, proper patch formatting can
> be had with |git format-patch|. The tools cannot create the necessary text,
> though, so read the instructions below anyway.
>
> The canonical patch subject line is:
>
> Subject: [PATCH 001/123] subsystem: summary phrase
>
> The canonical patch message body contains the following:
>
> * A |from| line specifying the patch author, followed by an empty line
> (only needed if the person sending the patch is not the author).
> * The body of the explanation, line wrapped at 75 columns, which will be
> copied to the permanent changelog to describe this patch.
> * An empty line.
> * The |Signed-off-by:| lines, described above, which will also go in the
> changelog.
> * A marker line containing simply |---|.
> * Any additional comments not suitable for the changelog.
> * The actual patch (|diff| output).
>
>
> - Armin
>
>> Cheers,
>>
>> Richard
>>
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-01 23:41 ` Mark Hatle
0 siblings, 0 replies; 55+ messages in thread
From: Mark Hatle @ 2019-04-01 23:41 UTC (permalink / raw)
To: akuster808, Richard Purdie,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
On 4/1/19 6:20 PM, akuster808 wrote:
>
>
> On 4/1/19 4:02 PM, Richard Purdie wrote:
>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>> Hello,
>>>
>>> I have noticed a large number of git commits with no header
>>> information being accepted.
>> Can you be more specific about what "no header information" means? You
>> mean a shortlog and no full log message?
> Commits with just a "subject" and signoff. No additional information
If you can convey the reason for the change in just the subject, that is
acceptable.. but there is -always- supposed to be a signed-off-by line according
to our guidelines.
So if you see this, I think we need to step back and figure out where and why
it's happening and get it resolved in the future.
(Places I've seen in the past were one-off mistakes and clearly that -- so it
wasn't anything that we needed to work on a correction.)
--Mark
> We tend to reference back to how the kernel does things.
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> These two sections in particular.
>
>
> 2) Describe your changes
>
> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> a new feature, there must be an underlying problem that motivated you to do this
> work. Convince the reviewer that there is a problem worth fixing and that it
> makes sense for them to read past the first paragraph.
>
>
> along with this section.
>
>
> 14) The canonical patch format
>
> This section describes how the patch itself should be formatted. Note that, if
> you have your patches stored in a |git| repository, proper patch formatting can
> be had with |git format-patch|. The tools cannot create the necessary text,
> though, so read the instructions below anyway.
>
> The canonical patch subject line is:
>
> Subject: [PATCH 001/123] subsystem: summary phrase
>
> The canonical patch message body contains the following:
>
> * A |from| line specifying the patch author, followed by an empty line
> (only needed if the person sending the patch is not the author).
> * The body of the explanation, line wrapped at 75 columns, which will be
> copied to the permanent changelog to describe this patch.
> * An empty line.
> * The |Signed-off-by:| lines, described above, which will also go in the
> changelog.
> * A marker line containing simply |---|.
> * Any additional comments not suitable for the changelog.
> * The actual patch (|diff| output).
>
>
> - Armin
>
>> Cheers,
>>
>> Richard
>>
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-01 23:41 ` Mark Hatle
(?)
@ 2019-04-02 4:45 ` Jon Mason
-1 siblings, 0 replies; 55+ messages in thread
From: Jon Mason @ 2019-04-02 4:45 UTC (permalink / raw)
To: Mark Hatle
Cc: yocto, akuster808, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
>
> On 4/1/19 6:20 PM, akuster808 wrote:
> >
> >
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >>> Hello,
> >>>
> >>> I have noticed a large number of git commits with no header
> >>> information being accepted.
> >> Can you be more specific about what "no header information" means? You
> >> mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
>
> If you can convey the reason for the change in just the subject, that is
> acceptable.. but there is -always- supposed to be a signed-off-by line according
> to our guidelines.
>
> So if you see this, I think we need to step back and figure out where and why
> it's happening and get it resolved in the future.
>
> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> wasn't anything that we needed to work on a correction.)
>
> --Mark
>
> > We tend to reference back to how the kernel does things.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> >
> >
> > 2) Describe your changes
> >
> > Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > a new feature, there must be an underlying problem that motivated you to do this
> > work. Convince the reviewer that there is a problem worth fixing and that it
> > makes sense for them to read past the first paragraph.
> >
> >
> > along with this section.
> >
> >
> > 14) The canonical patch format
> >
> > This section describes how the patch itself should be formatted. Note that, if
> > you have your patches stored in a |git| repository, proper patch formatting can
> > be had with |git format-patch|. The tools cannot create the necessary text,
> > though, so read the instructions below anyway.
> >
> > The canonical patch subject line is:
> >
> > Subject: [PATCH 001/123] subsystem: summary phrase
> >
> > The canonical patch message body contains the following:
> >
> > * A |from| line specifying the patch author, followed by an empty line
> > (only needed if the person sending the patch is not the author).
> > * The body of the explanation, line wrapped at 75 columns, which will be
> > copied to the permanent changelog to describe this patch.
> > * An empty line.
> > * The |Signed-off-by:| lines, described above, which will also go in the
> > changelog.
> > * A marker line containing simply |---|.
> > * Any additional comments not suitable for the changelog.
> > * The actual patch (|diff| output).
> >
> >
> > - Armin
There are existing git hooks that can be used to detect and fail to
merge patches like this. For Linux, I have the following in
.git/hooks/pre-commit
#!/bin/sh
exec git diff --cached | scripts/checkpatch.pl -
Perhaps something similar can be added to check for this.
Thanks,
Jon
> >
> >> Cheers,
> >>
> >> Richard
> >>
> >
> >
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-02 4:45 ` Jon Mason
0 siblings, 0 replies; 55+ messages in thread
From: Jon Mason @ 2019-04-02 4:45 UTC (permalink / raw)
To: Mark Hatle
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
>
> On 4/1/19 6:20 PM, akuster808 wrote:
> >
> >
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >>> Hello,
> >>>
> >>> I have noticed a large number of git commits with no header
> >>> information being accepted.
> >> Can you be more specific about what "no header information" means? You
> >> mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
>
> If you can convey the reason for the change in just the subject, that is
> acceptable.. but there is -always- supposed to be a signed-off-by line according
> to our guidelines.
>
> So if you see this, I think we need to step back and figure out where and why
> it's happening and get it resolved in the future.
>
> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> wasn't anything that we needed to work on a correction.)
>
> --Mark
>
> > We tend to reference back to how the kernel does things.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> >
> >
> > 2) Describe your changes
> >
> > Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > a new feature, there must be an underlying problem that motivated you to do this
> > work. Convince the reviewer that there is a problem worth fixing and that it
> > makes sense for them to read past the first paragraph.
> >
> >
> > along with this section.
> >
> >
> > 14) The canonical patch format
> >
> > This section describes how the patch itself should be formatted. Note that, if
> > you have your patches stored in a |git| repository, proper patch formatting can
> > be had with |git format-patch|. The tools cannot create the necessary text,
> > though, so read the instructions below anyway.
> >
> > The canonical patch subject line is:
> >
> > Subject: [PATCH 001/123] subsystem: summary phrase
> >
> > The canonical patch message body contains the following:
> >
> > * A |from| line specifying the patch author, followed by an empty line
> > (only needed if the person sending the patch is not the author).
> > * The body of the explanation, line wrapped at 75 columns, which will be
> > copied to the permanent changelog to describe this patch.
> > * An empty line.
> > * The |Signed-off-by:| lines, described above, which will also go in the
> > changelog.
> > * A marker line containing simply |---|.
> > * Any additional comments not suitable for the changelog.
> > * The actual patch (|diff| output).
> >
> >
> > - Armin
There are existing git hooks that can be used to detect and fail to
merge patches like this. For Linux, I have the following in
.git/hooks/pre-commit
#!/bin/sh
exec git diff --cached | scripts/checkpatch.pl -
Perhaps something similar can be added to check for this.
Thanks,
Jon
> >
> >> Cheers,
> >>
> >> Richard
> >>
> >
> >
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-02 4:45 ` Jon Mason
0 siblings, 0 replies; 55+ messages in thread
From: Jon Mason @ 2019-04-02 4:45 UTC (permalink / raw)
To: Mark Hatle
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
>
> On 4/1/19 6:20 PM, akuster808 wrote:
> >
> >
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >>> Hello,
> >>>
> >>> I have noticed a large number of git commits with no header
> >>> information being accepted.
> >> Can you be more specific about what "no header information" means? You
> >> mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
>
> If you can convey the reason for the change in just the subject, that is
> acceptable.. but there is -always- supposed to be a signed-off-by line according
> to our guidelines.
>
> So if you see this, I think we need to step back and figure out where and why
> it's happening and get it resolved in the future.
>
> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> wasn't anything that we needed to work on a correction.)
>
> --Mark
>
> > We tend to reference back to how the kernel does things.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> >
> >
> > 2) Describe your changes
> >
> > Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > a new feature, there must be an underlying problem that motivated you to do this
> > work. Convince the reviewer that there is a problem worth fixing and that it
> > makes sense for them to read past the first paragraph.
> >
> >
> > along with this section.
> >
> >
> > 14) The canonical patch format
> >
> > This section describes how the patch itself should be formatted. Note that, if
> > you have your patches stored in a |git| repository, proper patch formatting can
> > be had with |git format-patch|. The tools cannot create the necessary text,
> > though, so read the instructions below anyway.
> >
> > The canonical patch subject line is:
> >
> > Subject: [PATCH 001/123] subsystem: summary phrase
> >
> > The canonical patch message body contains the following:
> >
> > * A |from| line specifying the patch author, followed by an empty line
> > (only needed if the person sending the patch is not the author).
> > * The body of the explanation, line wrapped at 75 columns, which will be
> > copied to the permanent changelog to describe this patch.
> > * An empty line.
> > * The |Signed-off-by:| lines, described above, which will also go in the
> > changelog.
> > * A marker line containing simply |---|.
> > * Any additional comments not suitable for the changelog.
> > * The actual patch (|diff| output).
> >
> >
> > - Armin
There are existing git hooks that can be used to detect and fail to
merge patches like this. For Linux, I have the following in
.git/hooks/pre-commit
#!/bin/sh
exec git diff --cached | scripts/checkpatch.pl -
Perhaps something similar can be added to check for this.
Thanks,
Jon
> >
> >> Cheers,
> >>
> >> Richard
> >>
> >
> >
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-01 23:20 ` akuster808
@ 2019-04-02 6:51 ` Adrian Bunk
-1 siblings, 0 replies; 55+ messages in thread
From: Adrian Bunk @ 2019-04-02 6:51 UTC (permalink / raw)
To: akuster808
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>
>
> On 4/1/19 4:02 PM, Richard Purdie wrote:
> > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >> Hello,
> >>
> >> I have noticed a large number of git commits with no header
> >> information being accepted.
> > Can you be more specific about what "no header information" means? You
> > mean a shortlog and no full log message?
> Commits with just a "subject" and signoff. No additional information
>
> We tend to reference back to how the kernel does things.
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> These two sections in particular.
>
>
> 2) Describe your changes
>
> Describe your problem. Whether your patch is a one-line bug fix or 5000
> lines of a new feature, there must be an underlying problem that
> motivated you to do this work. Convince the reviewer that there is a
> problem worth fixing and that it makes sense for them to read past the
> first paragraph.
>...
The kernel does not have "upgrade foo to the latest upstream version" commits.
With the Automatic Upgrade Helper this is a semi-automatic task, and
most of the time there is no specific motivation other than upgrading
to the latest upstream version.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-02 6:51 ` Adrian Bunk
0 siblings, 0 replies; 55+ messages in thread
From: Adrian Bunk @ 2019-04-02 6:51 UTC (permalink / raw)
To: akuster808
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>
>
> On 4/1/19 4:02 PM, Richard Purdie wrote:
> > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >> Hello,
> >>
> >> I have noticed a large number of git commits with no header
> >> information being accepted.
> > Can you be more specific about what "no header information" means? You
> > mean a shortlog and no full log message?
> Commits with just a "subject" and signoff. No additional information
>
> We tend to reference back to how the kernel does things.
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> These two sections in particular.
>
>
> 2) Describe your changes
>
> Describe your problem. Whether your patch is a one-line bug fix or 5000
> lines of a new feature, there must be an underlying problem that
> motivated you to do this work. Convince the reviewer that there is a
> problem worth fixing and that it makes sense for them to read past the
> first paragraph.
>...
The kernel does not have "upgrade foo to the latest upstream version" commits.
With the Automatic Upgrade Helper this is a semi-automatic task, and
most of the time there is no specific motivation other than upgrading
to the latest upstream version.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-02 6:51 ` Adrian Bunk
(?)
@ 2019-04-02 19:46 ` Tom Rini
-1 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-02 19:46 UTC (permalink / raw)
To: Adrian Bunk
Cc: yocto, akuster808, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> >
> >
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
> >
> > We tend to reference back to how the kernel does things.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> >
> >
> > 2) Describe your changes
> >
> > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > lines of a new feature, there must be an underlying problem that
> > motivated you to do this work. Convince the reviewer that there is a
> > problem worth fixing and that it makes sense for them to read past the
> > first paragraph.
> >...
>
> The kernel does not have "upgrade foo to the latest upstream version" commits.
>
> With the Automatic Upgrade Helper this is a semi-automatic task, and
> most of the time there is no specific motivation other than upgrading
> to the latest upstream version.
But since that's just filling in a template the body can also be a
template perhaps with useful AUH data (run at ... by ... ?) ?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-02 19:46 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-02 19:46 UTC (permalink / raw)
To: Adrian Bunk
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> >
> >
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
> >
> > We tend to reference back to how the kernel does things.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> >
> >
> > 2) Describe your changes
> >
> > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > lines of a new feature, there must be an underlying problem that
> > motivated you to do this work. Convince the reviewer that there is a
> > problem worth fixing and that it makes sense for them to read past the
> > first paragraph.
> >...
>
> The kernel does not have "upgrade foo to the latest upstream version" commits.
>
> With the Automatic Upgrade Helper this is a semi-automatic task, and
> most of the time there is no specific motivation other than upgrading
> to the latest upstream version.
But since that's just filling in a template the body can also be a
template perhaps with useful AUH data (run at ... by ... ?) ?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-02 19:46 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-02 19:46 UTC (permalink / raw)
To: Adrian Bunk
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> >
> >
> > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >> Hello,
> > >>
> > >> I have noticed a large number of git commits with no header
> > >> information being accepted.
> > > Can you be more specific about what "no header information" means? You
> > > mean a shortlog and no full log message?
> > Commits with just a "subject" and signoff. No additional information
> >
> > We tend to reference back to how the kernel does things.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > These two sections in particular.
> >
> >
> > 2) Describe your changes
> >
> > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > lines of a new feature, there must be an underlying problem that
> > motivated you to do this work. Convince the reviewer that there is a
> > problem worth fixing and that it makes sense for them to read past the
> > first paragraph.
> >...
>
> The kernel does not have "upgrade foo to the latest upstream version" commits.
>
> With the Automatic Upgrade Helper this is a semi-automatic task, and
> most of the time there is no specific motivation other than upgrading
> to the latest upstream version.
But since that's just filling in a template the body can also be a
template perhaps with useful AUH data (run at ... by ... ?) ?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-02 4:45 ` Jon Mason
@ 2019-04-02 19:47 ` Tom Rini
-1 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-02 19:47 UTC (permalink / raw)
To: Jon Mason
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]
On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> >
> > On 4/1/19 6:20 PM, akuster808 wrote:
> > >
> > >
> > > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>> Hello,
> > >>>
> > >>> I have noticed a large number of git commits with no header
> > >>> information being accepted.
> > >> Can you be more specific about what "no header information" means? You
> > >> mean a shortlog and no full log message?
> > > Commits with just a "subject" and signoff. No additional information
> >
> > If you can convey the reason for the change in just the subject, that is
> > acceptable.. but there is -always- supposed to be a signed-off-by line according
> > to our guidelines.
> >
> > So if you see this, I think we need to step back and figure out where and why
> > it's happening and get it resolved in the future.
> >
> > (Places I've seen in the past were one-off mistakes and clearly that -- so it
> > wasn't anything that we needed to work on a correction.)
> >
> > --Mark
> >
> > > We tend to reference back to how the kernel does things.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > > These two sections in particular.
> > >
> > >
> > > 2) Describe your changes
> > >
> > > Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > > a new feature, there must be an underlying problem that motivated you to do this
> > > work. Convince the reviewer that there is a problem worth fixing and that it
> > > makes sense for them to read past the first paragraph.
> > >
> > >
> > > along with this section.
> > >
> > >
> > > 14) The canonical patch format
> > >
> > > This section describes how the patch itself should be formatted. Note that, if
> > > you have your patches stored in a |git| repository, proper patch formatting can
> > > be had with |git format-patch|. The tools cannot create the necessary text,
> > > though, so read the instructions below anyway.
> > >
> > > The canonical patch subject line is:
> > >
> > > Subject: [PATCH 001/123] subsystem: summary phrase
> > >
> > > The canonical patch message body contains the following:
> > >
> > > * A |from| line specifying the patch author, followed by an empty line
> > > (only needed if the person sending the patch is not the author).
> > > * The body of the explanation, line wrapped at 75 columns, which will be
> > > copied to the permanent changelog to describe this patch.
> > > * An empty line.
> > > * The |Signed-off-by:| lines, described above, which will also go in the
> > > changelog.
> > > * A marker line containing simply |---|.
> > > * Any additional comments not suitable for the changelog.
> > > * The actual patch (|diff| output).
> > >
> > >
> > > - Armin
>
> There are existing git hooks that can be used to detect and fail to
> merge patches like this. For Linux, I have the following in
> .git/hooks/pre-commit
> #!/bin/sh
> exec git diff --cached | scripts/checkpatch.pl -
FWIW, over in U-Boot land I do:
./scripts/checkpatch.pl -q --git origin/master..
as part of checking things prior to pushing to master.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-02 19:47 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-02 19:47 UTC (permalink / raw)
To: Jon Mason
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]
On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> >
> > On 4/1/19 6:20 PM, akuster808 wrote:
> > >
> > >
> > > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>> Hello,
> > >>>
> > >>> I have noticed a large number of git commits with no header
> > >>> information being accepted.
> > >> Can you be more specific about what "no header information" means? You
> > >> mean a shortlog and no full log message?
> > > Commits with just a "subject" and signoff. No additional information
> >
> > If you can convey the reason for the change in just the subject, that is
> > acceptable.. but there is -always- supposed to be a signed-off-by line according
> > to our guidelines.
> >
> > So if you see this, I think we need to step back and figure out where and why
> > it's happening and get it resolved in the future.
> >
> > (Places I've seen in the past were one-off mistakes and clearly that -- so it
> > wasn't anything that we needed to work on a correction.)
> >
> > --Mark
> >
> > > We tend to reference back to how the kernel does things.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > > These two sections in particular.
> > >
> > >
> > > 2) Describe your changes
> > >
> > > Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > > a new feature, there must be an underlying problem that motivated you to do this
> > > work. Convince the reviewer that there is a problem worth fixing and that it
> > > makes sense for them to read past the first paragraph.
> > >
> > >
> > > along with this section.
> > >
> > >
> > > 14) The canonical patch format
> > >
> > > This section describes how the patch itself should be formatted. Note that, if
> > > you have your patches stored in a |git| repository, proper patch formatting can
> > > be had with |git format-patch|. The tools cannot create the necessary text,
> > > though, so read the instructions below anyway.
> > >
> > > The canonical patch subject line is:
> > >
> > > Subject: [PATCH 001/123] subsystem: summary phrase
> > >
> > > The canonical patch message body contains the following:
> > >
> > > * A |from| line specifying the patch author, followed by an empty line
> > > (only needed if the person sending the patch is not the author).
> > > * The body of the explanation, line wrapped at 75 columns, which will be
> > > copied to the permanent changelog to describe this patch.
> > > * An empty line.
> > > * The |Signed-off-by:| lines, described above, which will also go in the
> > > changelog.
> > > * A marker line containing simply |---|.
> > > * Any additional comments not suitable for the changelog.
> > > * The actual patch (|diff| output).
> > >
> > >
> > > - Armin
>
> There are existing git hooks that can be used to detect and fail to
> merge patches like this. For Linux, I have the following in
> .git/hooks/pre-commit
> #!/bin/sh
> exec git diff --cached | scripts/checkpatch.pl -
FWIW, over in U-Boot land I do:
./scripts/checkpatch.pl -q --git origin/master..
as part of checking things prior to pushing to master.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-02 19:46 ` Tom Rini
@ 2019-04-02 20:58 ` akuster808
-1 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-02 20:58 UTC (permalink / raw)
To: Tom Rini, Adrian Bunk
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On 4/2/19 12:46 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
>> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>>>
>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>> Hello,
>>>>>
>>>>> I have noticed a large number of git commits with no header
>>>>> information being accepted.
>>>> Can you be more specific about what "no header information" means? You
>>>> mean a shortlog and no full log message?
>>> Commits with just a "subject" and signoff. No additional information
>>>
>>> We tend to reference back to how the kernel does things.
>>>
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>> These two sections in particular.
>>>
>>>
>>> 2) Describe your changes
>>>
>>> Describe your problem. Whether your patch is a one-line bug fix or 5000
>>> lines of a new feature, there must be an underlying problem that
>>> motivated you to do this work. Convince the reviewer that there is a
>>> problem worth fixing and that it makes sense for them to read past the
>>> first paragraph.
>>> ...
>> The kernel does not have "upgrade foo to the latest upstream version" commits.
>>
>> With the Automatic Upgrade Helper this is a semi-automatic task, and
>> most of the time there is no specific motivation other than upgrading
>> to the latest upstream version.
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?..
Maybe, if someone want to enhance the AUH.
- armin
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-02 20:58 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-02 20:58 UTC (permalink / raw)
To: Tom Rini, Adrian Bunk
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On 4/2/19 12:46 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
>> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>>>
>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>> Hello,
>>>>>
>>>>> I have noticed a large number of git commits with no header
>>>>> information being accepted.
>>>> Can you be more specific about what "no header information" means? You
>>>> mean a shortlog and no full log message?
>>> Commits with just a "subject" and signoff. No additional information
>>>
>>> We tend to reference back to how the kernel does things.
>>>
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>> These two sections in particular.
>>>
>>>
>>> 2) Describe your changes
>>>
>>> Describe your problem. Whether your patch is a one-line bug fix or 5000
>>> lines of a new feature, there must be an underlying problem that
>>> motivated you to do this work. Convince the reviewer that there is a
>>> problem worth fixing and that it makes sense for them to read past the
>>> first paragraph.
>>> ...
>> The kernel does not have "upgrade foo to the latest upstream version" commits.
>>
>> With the Automatic Upgrade Helper this is a semi-automatic task, and
>> most of the time there is no specific motivation other than upgrading
>> to the latest upstream version.
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?..
Maybe, if someone want to enhance the AUH.
- armin
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-02 19:47 ` Tom Rini
(?)
@ 2019-04-02 21:24 ` akuster808
-1 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-02 21:24 UTC (permalink / raw)
To: Tom Rini, Jon Mason
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1.1.1: Type: text/plain, Size: 3559 bytes --]
On 4/2/19 12:47 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
>> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 4/1/19 6:20 PM, akuster808 wrote:
>>>>
>>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have noticed a large number of git commits with no header
>>>>>> information being accepted.
>>>>> Can you be more specific about what "no header information" means? You
>>>>> mean a shortlog and no full log message?
>>>> Commits with just a "subject" and signoff. No additional information
>>> If you can convey the reason for the change in just the subject, that is
>>> acceptable.. but there is -always- supposed to be a signed-off-by line according
>>> to our guidelines.
>>>
>>> So if you see this, I think we need to step back and figure out where and why
>>> it's happening and get it resolved in the future.
>>>
>>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
>>> wasn't anything that we needed to work on a correction.)
>>>
>>> --Mark
>>>
>>>> We tend to reference back to how the kernel does things.
>>>>
>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>>> These two sections in particular.
>>>>
>>>>
>>>> 2) Describe your changes
>>>>
>>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
>>>> a new feature, there must be an underlying problem that motivated you to do this
>>>> work. Convince the reviewer that there is a problem worth fixing and that it
>>>> makes sense for them to read past the first paragraph.
>>>>
>>>>
>>>> along with this section.
>>>>
>>>>
>>>> 14) The canonical patch format
>>>>
>>>> This section describes how the patch itself should be formatted. Note that, if
>>>> you have your patches stored in a |git| repository, proper patch formatting can
>>>> be had with |git format-patch|. The tools cannot create the necessary text,
>>>> though, so read the instructions below anyway.
>>>>
>>>> The canonical patch subject line is:
>>>>
>>>> Subject: [PATCH 001/123] subsystem: summary phrase
>>>>
>>>> The canonical patch message body contains the following:
>>>>
>>>> * A |from| line specifying the patch author, followed by an empty line
>>>> (only needed if the person sending the patch is not the author).
>>>> * The body of the explanation, line wrapped at 75 columns, which will be
>>>> copied to the permanent changelog to describe this patch.
>>>> * An empty line.
>>>> * The |Signed-off-by:| lines, described above, which will also go in the
>>>> changelog.
>>>> * A marker line containing simply |---|.
>>>> * Any additional comments not suitable for the changelog.
>>>> * The actual patch (|diff| output).
>>>>
>>>>
>>>> - Armin
>> There are existing git hooks that can be used to detect and fail to
>> merge patches like this. For Linux, I have the following in
>> .git/hooks/pre-commit
>> #!/bin/sh
>> exec git diff --cached | scripts/checkpatch.pl -
> FWIW, over in U-Boot land I do:
> ./scripts/checkpatch.pl -q --git origin/master..
> as part of checking things prior to pushing to master.
Having hooks is fine but after the fact. It puts the burden back on the
Layer maintainer to resolve. If we think more info is better, it needs
to happen at time of change submittal.
- armin
>
>
[-- Attachment #1.1.2: Type: text/html, Size: 5046 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-02 21:24 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-02 21:24 UTC (permalink / raw)
To: Tom Rini, Jon Mason
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1.1.1: Type: text/plain, Size: 3559 bytes --]
On 4/2/19 12:47 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
>> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 4/1/19 6:20 PM, akuster808 wrote:
>>>>
>>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have noticed a large number of git commits with no header
>>>>>> information being accepted.
>>>>> Can you be more specific about what "no header information" means? You
>>>>> mean a shortlog and no full log message?
>>>> Commits with just a "subject" and signoff. No additional information
>>> If you can convey the reason for the change in just the subject, that is
>>> acceptable.. but there is -always- supposed to be a signed-off-by line according
>>> to our guidelines.
>>>
>>> So if you see this, I think we need to step back and figure out where and why
>>> it's happening and get it resolved in the future.
>>>
>>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
>>> wasn't anything that we needed to work on a correction.)
>>>
>>> --Mark
>>>
>>>> We tend to reference back to how the kernel does things.
>>>>
>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>>> These two sections in particular.
>>>>
>>>>
>>>> 2) Describe your changes
>>>>
>>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
>>>> a new feature, there must be an underlying problem that motivated you to do this
>>>> work. Convince the reviewer that there is a problem worth fixing and that it
>>>> makes sense for them to read past the first paragraph.
>>>>
>>>>
>>>> along with this section.
>>>>
>>>>
>>>> 14) The canonical patch format
>>>>
>>>> This section describes how the patch itself should be formatted. Note that, if
>>>> you have your patches stored in a |git| repository, proper patch formatting can
>>>> be had with |git format-patch|. The tools cannot create the necessary text,
>>>> though, so read the instructions below anyway.
>>>>
>>>> The canonical patch subject line is:
>>>>
>>>> Subject: [PATCH 001/123] subsystem: summary phrase
>>>>
>>>> The canonical patch message body contains the following:
>>>>
>>>> * A |from| line specifying the patch author, followed by an empty line
>>>> (only needed if the person sending the patch is not the author).
>>>> * The body of the explanation, line wrapped at 75 columns, which will be
>>>> copied to the permanent changelog to describe this patch.
>>>> * An empty line.
>>>> * The |Signed-off-by:| lines, described above, which will also go in the
>>>> changelog.
>>>> * A marker line containing simply |---|.
>>>> * Any additional comments not suitable for the changelog.
>>>> * The actual patch (|diff| output).
>>>>
>>>>
>>>> - Armin
>> There are existing git hooks that can be used to detect and fail to
>> merge patches like this. For Linux, I have the following in
>> .git/hooks/pre-commit
>> #!/bin/sh
>> exec git diff --cached | scripts/checkpatch.pl -
> FWIW, over in U-Boot land I do:
> ./scripts/checkpatch.pl -q --git origin/master..
> as part of checking things prior to pushing to master.
Having hooks is fine but after the fact. It puts the burden back on the
Layer maintainer to resolve. If we think more info is better, it needs
to happen at time of change submittal.
- armin
>
>
[-- Attachment #1.1.2: Type: text/html, Size: 5046 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-02 21:24 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-02 21:24 UTC (permalink / raw)
To: Tom Rini, Jon Mason
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
[-- Attachment #1.1.1: Type: text/plain, Size: 3559 bytes --]
On 4/2/19 12:47 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
>> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 4/1/19 6:20 PM, akuster808 wrote:
>>>>
>>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have noticed a large number of git commits with no header
>>>>>> information being accepted.
>>>>> Can you be more specific about what "no header information" means? You
>>>>> mean a shortlog and no full log message?
>>>> Commits with just a "subject" and signoff. No additional information
>>> If you can convey the reason for the change in just the subject, that is
>>> acceptable.. but there is -always- supposed to be a signed-off-by line according
>>> to our guidelines.
>>>
>>> So if you see this, I think we need to step back and figure out where and why
>>> it's happening and get it resolved in the future.
>>>
>>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
>>> wasn't anything that we needed to work on a correction.)
>>>
>>> --Mark
>>>
>>>> We tend to reference back to how the kernel does things.
>>>>
>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>>> These two sections in particular.
>>>>
>>>>
>>>> 2) Describe your changes
>>>>
>>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
>>>> a new feature, there must be an underlying problem that motivated you to do this
>>>> work. Convince the reviewer that there is a problem worth fixing and that it
>>>> makes sense for them to read past the first paragraph.
>>>>
>>>>
>>>> along with this section.
>>>>
>>>>
>>>> 14) The canonical patch format
>>>>
>>>> This section describes how the patch itself should be formatted. Note that, if
>>>> you have your patches stored in a |git| repository, proper patch formatting can
>>>> be had with |git format-patch|. The tools cannot create the necessary text,
>>>> though, so read the instructions below anyway.
>>>>
>>>> The canonical patch subject line is:
>>>>
>>>> Subject: [PATCH 001/123] subsystem: summary phrase
>>>>
>>>> The canonical patch message body contains the following:
>>>>
>>>> * A |from| line specifying the patch author, followed by an empty line
>>>> (only needed if the person sending the patch is not the author).
>>>> * The body of the explanation, line wrapped at 75 columns, which will be
>>>> copied to the permanent changelog to describe this patch.
>>>> * An empty line.
>>>> * The |Signed-off-by:| lines, described above, which will also go in the
>>>> changelog.
>>>> * A marker line containing simply |---|.
>>>> * Any additional comments not suitable for the changelog.
>>>> * The actual patch (|diff| output).
>>>>
>>>>
>>>> - Armin
>> There are existing git hooks that can be used to detect and fail to
>> merge patches like this. For Linux, I have the following in
>> .git/hooks/pre-commit
>> #!/bin/sh
>> exec git diff --cached | scripts/checkpatch.pl -
> FWIW, over in U-Boot land I do:
> ./scripts/checkpatch.pl -q --git origin/master..
> as part of checking things prior to pushing to master.
Having hooks is fine but after the fact. It puts the burden back on the
Layer maintainer to resolve. If we think more info is better, it needs
to happen at time of change submittal.
- armin
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-02 21:24 ` [oe] " akuster808
(?)
@ 2019-04-03 0:45 ` Tom Rini
-1 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-03 0:45 UTC (permalink / raw)
To: akuster808
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List
[-- Attachment #1: Type: text/plain, Size: 3973 bytes --]
On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
>
>
> On 4/2/19 12:47 PM, Tom Rini wrote:
> > On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> >>> On 4/1/19 6:20 PM, akuster808 wrote:
> >>>>
> >>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
> >>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> I have noticed a large number of git commits with no header
> >>>>>> information being accepted.
> >>>>> Can you be more specific about what "no header information" means? You
> >>>>> mean a shortlog and no full log message?
> >>>> Commits with just a "subject" and signoff. No additional information
> >>> If you can convey the reason for the change in just the subject, that is
> >>> acceptable.. but there is -always- supposed to be a signed-off-by line according
> >>> to our guidelines.
> >>>
> >>> So if you see this, I think we need to step back and figure out where and why
> >>> it's happening and get it resolved in the future.
> >>>
> >>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> >>> wasn't anything that we needed to work on a correction.)
> >>>
> >>> --Mark
> >>>
> >>>> We tend to reference back to how the kernel does things.
> >>>>
> >>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >>>> These two sections in particular.
> >>>>
> >>>>
> >>>> 2) Describe your changes
> >>>>
> >>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> >>>> a new feature, there must be an underlying problem that motivated you to do this
> >>>> work. Convince the reviewer that there is a problem worth fixing and that it
> >>>> makes sense for them to read past the first paragraph.
> >>>>
> >>>>
> >>>> along with this section.
> >>>>
> >>>>
> >>>> 14) The canonical patch format
> >>>>
> >>>> This section describes how the patch itself should be formatted. Note that, if
> >>>> you have your patches stored in a |git| repository, proper patch formatting can
> >>>> be had with |git format-patch|. The tools cannot create the necessary text,
> >>>> though, so read the instructions below anyway.
> >>>>
> >>>> The canonical patch subject line is:
> >>>>
> >>>> Subject: [PATCH 001/123] subsystem: summary phrase
> >>>>
> >>>> The canonical patch message body contains the following:
> >>>>
> >>>> * A |from| line specifying the patch author, followed by an empty line
> >>>> (only needed if the person sending the patch is not the author).
> >>>> * The body of the explanation, line wrapped at 75 columns, which will be
> >>>> copied to the permanent changelog to describe this patch.
> >>>> * An empty line.
> >>>> * The |Signed-off-by:| lines, described above, which will also go in the
> >>>> changelog.
> >>>> * A marker line containing simply |---|.
> >>>> * Any additional comments not suitable for the changelog.
> >>>> * The actual patch (|diff| output).
> >>>>
> >>>>
> >>>> - Armin
> >> There are existing git hooks that can be used to detect and fail to
> >> merge patches like this. For Linux, I have the following in
> >> .git/hooks/pre-commit
> >> #!/bin/sh
> >> exec git diff --cached | scripts/checkpatch.pl -
> > FWIW, over in U-Boot land I do:
> > ./scripts/checkpatch.pl -q --git origin/master..
> > as part of checking things prior to pushing to master.
> Having hooks is fine but after the fact. It puts the burden back on the
> Layer maintainer to resolve. If we think more info is better, it needs
> to happen at time of change submittal.
Note that I'm not talking about a hook, I'm talking about what's part of
my CI process. And when something pops up there is when I grab the
patch in question and push back on the submitter.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-03 0:45 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-03 0:45 UTC (permalink / raw)
To: akuster808
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List
[-- Attachment #1: Type: text/plain, Size: 3973 bytes --]
On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
>
>
> On 4/2/19 12:47 PM, Tom Rini wrote:
> > On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> >>> On 4/1/19 6:20 PM, akuster808 wrote:
> >>>>
> >>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
> >>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> I have noticed a large number of git commits with no header
> >>>>>> information being accepted.
> >>>>> Can you be more specific about what "no header information" means? You
> >>>>> mean a shortlog and no full log message?
> >>>> Commits with just a "subject" and signoff. No additional information
> >>> If you can convey the reason for the change in just the subject, that is
> >>> acceptable.. but there is -always- supposed to be a signed-off-by line according
> >>> to our guidelines.
> >>>
> >>> So if you see this, I think we need to step back and figure out where and why
> >>> it's happening and get it resolved in the future.
> >>>
> >>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> >>> wasn't anything that we needed to work on a correction.)
> >>>
> >>> --Mark
> >>>
> >>>> We tend to reference back to how the kernel does things.
> >>>>
> >>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >>>> These two sections in particular.
> >>>>
> >>>>
> >>>> 2) Describe your changes
> >>>>
> >>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> >>>> a new feature, there must be an underlying problem that motivated you to do this
> >>>> work. Convince the reviewer that there is a problem worth fixing and that it
> >>>> makes sense for them to read past the first paragraph.
> >>>>
> >>>>
> >>>> along with this section.
> >>>>
> >>>>
> >>>> 14) The canonical patch format
> >>>>
> >>>> This section describes how the patch itself should be formatted. Note that, if
> >>>> you have your patches stored in a |git| repository, proper patch formatting can
> >>>> be had with |git format-patch|. The tools cannot create the necessary text,
> >>>> though, so read the instructions below anyway.
> >>>>
> >>>> The canonical patch subject line is:
> >>>>
> >>>> Subject: [PATCH 001/123] subsystem: summary phrase
> >>>>
> >>>> The canonical patch message body contains the following:
> >>>>
> >>>> * A |from| line specifying the patch author, followed by an empty line
> >>>> (only needed if the person sending the patch is not the author).
> >>>> * The body of the explanation, line wrapped at 75 columns, which will be
> >>>> copied to the permanent changelog to describe this patch.
> >>>> * An empty line.
> >>>> * The |Signed-off-by:| lines, described above, which will also go in the
> >>>> changelog.
> >>>> * A marker line containing simply |---|.
> >>>> * Any additional comments not suitable for the changelog.
> >>>> * The actual patch (|diff| output).
> >>>>
> >>>>
> >>>> - Armin
> >> There are existing git hooks that can be used to detect and fail to
> >> merge patches like this. For Linux, I have the following in
> >> .git/hooks/pre-commit
> >> #!/bin/sh
> >> exec git diff --cached | scripts/checkpatch.pl -
> > FWIW, over in U-Boot land I do:
> > ./scripts/checkpatch.pl -q --git origin/master..
> > as part of checking things prior to pushing to master.
> Having hooks is fine but after the fact. It puts the burden back on the
> Layer maintainer to resolve. If we think more info is better, it needs
> to happen at time of change submittal.
Note that I'm not talking about a hook, I'm talking about what's part of
my CI process. And when something pops up there is when I grab the
patch in question and push back on the submitter.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-03 0:45 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-03 0:45 UTC (permalink / raw)
To: akuster808
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List
[-- Attachment #1: Type: text/plain, Size: 3973 bytes --]
On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
>
>
> On 4/2/19 12:47 PM, Tom Rini wrote:
> > On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> >>> On 4/1/19 6:20 PM, akuster808 wrote:
> >>>>
> >>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
> >>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> I have noticed a large number of git commits with no header
> >>>>>> information being accepted.
> >>>>> Can you be more specific about what "no header information" means? You
> >>>>> mean a shortlog and no full log message?
> >>>> Commits with just a "subject" and signoff. No additional information
> >>> If you can convey the reason for the change in just the subject, that is
> >>> acceptable.. but there is -always- supposed to be a signed-off-by line according
> >>> to our guidelines.
> >>>
> >>> So if you see this, I think we need to step back and figure out where and why
> >>> it's happening and get it resolved in the future.
> >>>
> >>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> >>> wasn't anything that we needed to work on a correction.)
> >>>
> >>> --Mark
> >>>
> >>>> We tend to reference back to how the kernel does things.
> >>>>
> >>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> >>>> These two sections in particular.
> >>>>
> >>>>
> >>>> 2) Describe your changes
> >>>>
> >>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> >>>> a new feature, there must be an underlying problem that motivated you to do this
> >>>> work. Convince the reviewer that there is a problem worth fixing and that it
> >>>> makes sense for them to read past the first paragraph.
> >>>>
> >>>>
> >>>> along with this section.
> >>>>
> >>>>
> >>>> 14) The canonical patch format
> >>>>
> >>>> This section describes how the patch itself should be formatted. Note that, if
> >>>> you have your patches stored in a |git| repository, proper patch formatting can
> >>>> be had with |git format-patch|. The tools cannot create the necessary text,
> >>>> though, so read the instructions below anyway.
> >>>>
> >>>> The canonical patch subject line is:
> >>>>
> >>>> Subject: [PATCH 001/123] subsystem: summary phrase
> >>>>
> >>>> The canonical patch message body contains the following:
> >>>>
> >>>> * A |from| line specifying the patch author, followed by an empty line
> >>>> (only needed if the person sending the patch is not the author).
> >>>> * The body of the explanation, line wrapped at 75 columns, which will be
> >>>> copied to the permanent changelog to describe this patch.
> >>>> * An empty line.
> >>>> * The |Signed-off-by:| lines, described above, which will also go in the
> >>>> changelog.
> >>>> * A marker line containing simply |---|.
> >>>> * Any additional comments not suitable for the changelog.
> >>>> * The actual patch (|diff| output).
> >>>>
> >>>>
> >>>> - Armin
> >> There are existing git hooks that can be used to detect and fail to
> >> merge patches like this. For Linux, I have the following in
> >> .git/hooks/pre-commit
> >> #!/bin/sh
> >> exec git diff --cached | scripts/checkpatch.pl -
> > FWIW, over in U-Boot land I do:
> > ./scripts/checkpatch.pl -q --git origin/master..
> > as part of checking things prior to pushing to master.
> Having hooks is fine but after the fact. It puts the burden back on the
> Layer maintainer to resolve. If we think more info is better, it needs
> to happen at time of change submittal.
Note that I'm not talking about a hook, I'm talking about what's part of
my CI process. And when something pops up there is when I grab the
patch in question and push back on the submitter.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-03 0:45 ` [oe] " Tom Rini
(?)
@ 2019-04-03 3:51 ` Jon Mason
-1 siblings, 0 replies; 55+ messages in thread
From: Jon Mason @ 2019-04-03 3:51 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, akuster808, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 7:45 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> >
> >
> > On 4/2/19 12:47 PM, Tom Rini wrote:
> > > On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> > >>> On 4/1/19 6:20 PM, akuster808 wrote:
> > >>>>
> > >>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> I have noticed a large number of git commits with no header
> > >>>>>> information being accepted.
> > >>>>> Can you be more specific about what "no header information" means? You
> > >>>>> mean a shortlog and no full log message?
> > >>>> Commits with just a "subject" and signoff. No additional information
> > >>> If you can convey the reason for the change in just the subject, that is
> > >>> acceptable.. but there is -always- supposed to be a signed-off-by line according
> > >>> to our guidelines.
> > >>>
> > >>> So if you see this, I think we need to step back and figure out where and why
> > >>> it's happening and get it resolved in the future.
> > >>>
> > >>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> > >>> wasn't anything that we needed to work on a correction.)
> > >>>
> > >>> --Mark
> > >>>
> > >>>> We tend to reference back to how the kernel does things.
> > >>>>
> > >>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > >>>> These two sections in particular.
> > >>>>
> > >>>>
> > >>>> 2) Describe your changes
> > >>>>
> > >>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > >>>> a new feature, there must be an underlying problem that motivated you to do this
> > >>>> work. Convince the reviewer that there is a problem worth fixing and that it
> > >>>> makes sense for them to read past the first paragraph.
> > >>>>
> > >>>>
> > >>>> along with this section.
> > >>>>
> > >>>>
> > >>>> 14) The canonical patch format
> > >>>>
> > >>>> This section describes how the patch itself should be formatted. Note that, if
> > >>>> you have your patches stored in a |git| repository, proper patch formatting can
> > >>>> be had with |git format-patch|. The tools cannot create the necessary text,
> > >>>> though, so read the instructions below anyway.
> > >>>>
> > >>>> The canonical patch subject line is:
> > >>>>
> > >>>> Subject: [PATCH 001/123] subsystem: summary phrase
> > >>>>
> > >>>> The canonical patch message body contains the following:
> > >>>>
> > >>>> * A |from| line specifying the patch author, followed by an empty line
> > >>>> (only needed if the person sending the patch is not the author).
> > >>>> * The body of the explanation, line wrapped at 75 columns, which will be
> > >>>> copied to the permanent changelog to describe this patch.
> > >>>> * An empty line.
> > >>>> * The |Signed-off-by:| lines, described above, which will also go in the
> > >>>> changelog.
> > >>>> * A marker line containing simply |---|.
> > >>>> * Any additional comments not suitable for the changelog.
> > >>>> * The actual patch (|diff| output).
> > >>>>
> > >>>>
> > >>>> - Armin
> > >> There are existing git hooks that can be used to detect and fail to
> > >> merge patches like this. For Linux, I have the following in
> > >> .git/hooks/pre-commit
> > >> #!/bin/sh
> > >> exec git diff --cached | scripts/checkpatch.pl -
> > > FWIW, over in U-Boot land I do:
> > > ./scripts/checkpatch.pl -q --git origin/master..
> > > as part of checking things prior to pushing to master.
> > Having hooks is fine but after the fact. It puts the burden back on the
> > Layer maintainer to resolve. If we think more info is better, it needs
> > to happen at time of change submittal.
>
> Note that I'm not talking about a hook, I'm talking about what's part of
> my CI process. And when something pops up there is when I grab the
> patch in question and push back on the submitter.
Exactly! I do the same things for the Linux stuff I own. I'll do a
git-am, then redir the output and publicly shame them. Public shaming
is a vastly underrated method of behavior modification.
Thanks,
Jon
>
> --
> Tom
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-03 3:51 ` Jon Mason
0 siblings, 0 replies; 55+ messages in thread
From: Jon Mason @ 2019-04-03 3:51 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 7:45 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> >
> >
> > On 4/2/19 12:47 PM, Tom Rini wrote:
> > > On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> > >>> On 4/1/19 6:20 PM, akuster808 wrote:
> > >>>>
> > >>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> I have noticed a large number of git commits with no header
> > >>>>>> information being accepted.
> > >>>>> Can you be more specific about what "no header information" means? You
> > >>>>> mean a shortlog and no full log message?
> > >>>> Commits with just a "subject" and signoff. No additional information
> > >>> If you can convey the reason for the change in just the subject, that is
> > >>> acceptable.. but there is -always- supposed to be a signed-off-by line according
> > >>> to our guidelines.
> > >>>
> > >>> So if you see this, I think we need to step back and figure out where and why
> > >>> it's happening and get it resolved in the future.
> > >>>
> > >>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> > >>> wasn't anything that we needed to work on a correction.)
> > >>>
> > >>> --Mark
> > >>>
> > >>>> We tend to reference back to how the kernel does things.
> > >>>>
> > >>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > >>>> These two sections in particular.
> > >>>>
> > >>>>
> > >>>> 2) Describe your changes
> > >>>>
> > >>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > >>>> a new feature, there must be an underlying problem that motivated you to do this
> > >>>> work. Convince the reviewer that there is a problem worth fixing and that it
> > >>>> makes sense for them to read past the first paragraph.
> > >>>>
> > >>>>
> > >>>> along with this section.
> > >>>>
> > >>>>
> > >>>> 14) The canonical patch format
> > >>>>
> > >>>> This section describes how the patch itself should be formatted. Note that, if
> > >>>> you have your patches stored in a |git| repository, proper patch formatting can
> > >>>> be had with |git format-patch|. The tools cannot create the necessary text,
> > >>>> though, so read the instructions below anyway.
> > >>>>
> > >>>> The canonical patch subject line is:
> > >>>>
> > >>>> Subject: [PATCH 001/123] subsystem: summary phrase
> > >>>>
> > >>>> The canonical patch message body contains the following:
> > >>>>
> > >>>> * A |from| line specifying the patch author, followed by an empty line
> > >>>> (only needed if the person sending the patch is not the author).
> > >>>> * The body of the explanation, line wrapped at 75 columns, which will be
> > >>>> copied to the permanent changelog to describe this patch.
> > >>>> * An empty line.
> > >>>> * The |Signed-off-by:| lines, described above, which will also go in the
> > >>>> changelog.
> > >>>> * A marker line containing simply |---|.
> > >>>> * Any additional comments not suitable for the changelog.
> > >>>> * The actual patch (|diff| output).
> > >>>>
> > >>>>
> > >>>> - Armin
> > >> There are existing git hooks that can be used to detect and fail to
> > >> merge patches like this. For Linux, I have the following in
> > >> .git/hooks/pre-commit
> > >> #!/bin/sh
> > >> exec git diff --cached | scripts/checkpatch.pl -
> > > FWIW, over in U-Boot land I do:
> > > ./scripts/checkpatch.pl -q --git origin/master..
> > > as part of checking things prior to pushing to master.
> > Having hooks is fine but after the fact. It puts the burden back on the
> > Layer maintainer to resolve. If we think more info is better, it needs
> > to happen at time of change submittal.
>
> Note that I'm not talking about a hook, I'm talking about what's part of
> my CI process. And when something pops up there is when I grab the
> patch in question and push back on the submitter.
Exactly! I do the same things for the Linux stuff I own. I'll do a
git-am, then redir the output and publicly shame them. Public shaming
is a vastly underrated method of behavior modification.
Thanks,
Jon
>
> --
> Tom
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-03 3:51 ` Jon Mason
0 siblings, 0 replies; 55+ messages in thread
From: Jon Mason @ 2019-04-03 3:51 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 7:45 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Apr 02, 2019 at 02:24:51PM -0700, akuster808 wrote:
> >
> >
> > On 4/2/19 12:47 PM, Tom Rini wrote:
> > > On Tue, Apr 02, 2019 at 04:45:16AM +0000, Jon Mason wrote:
> > >> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:
> > >>> On 4/1/19 6:20 PM, akuster808 wrote:
> > >>>>
> > >>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
> > >>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> I have noticed a large number of git commits with no header
> > >>>>>> information being accepted.
> > >>>>> Can you be more specific about what "no header information" means? You
> > >>>>> mean a shortlog and no full log message?
> > >>>> Commits with just a "subject" and signoff. No additional information
> > >>> If you can convey the reason for the change in just the subject, that is
> > >>> acceptable.. but there is -always- supposed to be a signed-off-by line according
> > >>> to our guidelines.
> > >>>
> > >>> So if you see this, I think we need to step back and figure out where and why
> > >>> it's happening and get it resolved in the future.
> > >>>
> > >>> (Places I've seen in the past were one-off mistakes and clearly that -- so it
> > >>> wasn't anything that we needed to work on a correction.)
> > >>>
> > >>> --Mark
> > >>>
> > >>>> We tend to reference back to how the kernel does things.
> > >>>>
> > >>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > >>>> These two sections in particular.
> > >>>>
> > >>>>
> > >>>> 2) Describe your changes
> > >>>>
> > >>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 lines of
> > >>>> a new feature, there must be an underlying problem that motivated you to do this
> > >>>> work. Convince the reviewer that there is a problem worth fixing and that it
> > >>>> makes sense for them to read past the first paragraph.
> > >>>>
> > >>>>
> > >>>> along with this section.
> > >>>>
> > >>>>
> > >>>> 14) The canonical patch format
> > >>>>
> > >>>> This section describes how the patch itself should be formatted. Note that, if
> > >>>> you have your patches stored in a |git| repository, proper patch formatting can
> > >>>> be had with |git format-patch|. The tools cannot create the necessary text,
> > >>>> though, so read the instructions below anyway.
> > >>>>
> > >>>> The canonical patch subject line is:
> > >>>>
> > >>>> Subject: [PATCH 001/123] subsystem: summary phrase
> > >>>>
> > >>>> The canonical patch message body contains the following:
> > >>>>
> > >>>> * A |from| line specifying the patch author, followed by an empty line
> > >>>> (only needed if the person sending the patch is not the author).
> > >>>> * The body of the explanation, line wrapped at 75 columns, which will be
> > >>>> copied to the permanent changelog to describe this patch.
> > >>>> * An empty line.
> > >>>> * The |Signed-off-by:| lines, described above, which will also go in the
> > >>>> changelog.
> > >>>> * A marker line containing simply |---|.
> > >>>> * Any additional comments not suitable for the changelog.
> > >>>> * The actual patch (|diff| output).
> > >>>>
> > >>>>
> > >>>> - Armin
> > >> There are existing git hooks that can be used to detect and fail to
> > >> merge patches like this. For Linux, I have the following in
> > >> .git/hooks/pre-commit
> > >> #!/bin/sh
> > >> exec git diff --cached | scripts/checkpatch.pl -
> > > FWIW, over in U-Boot land I do:
> > > ./scripts/checkpatch.pl -q --git origin/master..
> > > as part of checking things prior to pushing to master.
> > Having hooks is fine but after the fact. It puts the burden back on the
> > Layer maintainer to resolve. If we think more info is better, it needs
> > to happen at time of change submittal.
>
> Note that I'm not talking about a hook, I'm talking about what's part of
> my CI process. And when something pops up there is when I grab the
> patch in question and push back on the submitter.
Exactly! I do the same things for the Linux stuff I own. I'll do a
git-am, then redir the output and publicly shame them. Public shaming
is a vastly underrated method of behavior modification.
Thanks,
Jon
>
> --
> Tom
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
2019-04-02 19:46 ` Tom Rini
@ 2019-04-03 9:34 ` Adrian Bunk
-1 siblings, 0 replies; 55+ messages in thread
From: Adrian Bunk @ 2019-04-03 9:34 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Tue, Apr 02, 2019 at 03:46:14PM -0400, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> > On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> > >
> > >
> > > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > > >> Hello,
> > > >>
> > > >> I have noticed a large number of git commits with no header
> > > >> information being accepted.
> > > > Can you be more specific about what "no header information" means? You
> > > > mean a shortlog and no full log message?
> > > Commits with just a "subject" and signoff. No additional information
> > >
> > > We tend to reference back to how the kernel does things.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > > These two sections in particular.
> > >
> > >
> > > 2) Describe your changes
> > >
> > > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > > lines of a new feature, there must be an underlying problem that
> > > motivated you to do this work. Convince the reviewer that there is a
> > > problem worth fixing and that it makes sense for them to read past the
> > > first paragraph.
> > >...
> >
> > The kernel does not have "upgrade foo to the latest upstream version" commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the latest upstream version.
>
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?
That would be more trivial than useful.
And so far noone has stated any actual problem that would be solved
by adding such a new requirement.
> Tom
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Git commit process question.
@ 2019-04-03 9:34 ` Adrian Bunk
0 siblings, 0 replies; 55+ messages in thread
From: Adrian Bunk @ 2019-04-03 9:34 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
On Tue, Apr 02, 2019 at 03:46:14PM -0400, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
> > On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
> > >
> > >
> > > On 4/1/19 4:02 PM, Richard Purdie wrote:
> > > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
> > > >> Hello,
> > > >>
> > > >> I have noticed a large number of git commits with no header
> > > >> information being accepted.
> > > > Can you be more specific about what "no header information" means? You
> > > > mean a shortlog and no full log message?
> > > Commits with just a "subject" and signoff. No additional information
> > >
> > > We tend to reference back to how the kernel does things.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > > These two sections in particular.
> > >
> > >
> > > 2) Describe your changes
> > >
> > > Describe your problem. Whether your patch is a one-line bug fix or 5000
> > > lines of a new feature, there must be an underlying problem that
> > > motivated you to do this work. Convince the reviewer that there is a
> > > problem worth fixing and that it makes sense for them to read past the
> > > first paragraph.
> > >...
> >
> > The kernel does not have "upgrade foo to the latest upstream version" commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the latest upstream version.
>
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?
That would be more trivial than useful.
And so far noone has stated any actual problem that would be solved
by adding such a new requirement.
> Tom
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-02 19:46 ` Tom Rini
(?)
@ 2019-04-03 10:30 ` Burton, Ross
-1 siblings, 0 replies; 55+ messages in thread
From: Burton, Ross @ 2019-04-03 10:30 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Adrian Bunk
On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > The kernel does not have "upgrade foo to the latest upstream version" commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the latest upstream version.
>
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?
Apart from making the commit message longer what does this achieve?
The commit already has a timestamp and author.
Ross
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-03 10:30 ` Burton, Ross
0 siblings, 0 replies; 55+ messages in thread
From: Burton, Ross @ 2019-04-03 10:30 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Adrian Bunk
On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > The kernel does not have "upgrade foo to the latest upstream version" commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the latest upstream version.
>
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?
Apart from making the commit message longer what does this achieve?
The commit already has a timestamp and author.
Ross
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-03 10:30 ` Burton, Ross
0 siblings, 0 replies; 55+ messages in thread
From: Burton, Ross @ 2019-04-03 10:30 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Adrian Bunk
On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > The kernel does not have "upgrade foo to the latest upstream version" commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the latest upstream version.
>
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?
Apart from making the commit message longer what does this achieve?
The commit already has a timestamp and author.
Ross
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] [oe] Git commit process question.
2019-04-03 10:30 ` [oe] " Burton, Ross
(?)
@ 2019-04-03 10:38 ` Alexander Kanavin
-1 siblings, 0 replies; 55+ messages in thread
From: Alexander Kanavin @ 2019-04-03 10:38 UTC (permalink / raw)
To: Burton, Ross
Cc: Adrian Bunk, Tom Rini,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
Just to make clear, the AUH workflow does require the maintainer to
sign off and edit a commit message via 'git commit -s --reset-author
--amend' for every commit, so AUH does not get in the way of useful
commit messages.
Alex
On Wed, 3 Apr 2019 at 12:31, Burton, Ross <ross.burton@intel.com> wrote:
>
> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
>
> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-03 10:38 ` Alexander Kanavin
0 siblings, 0 replies; 55+ messages in thread
From: Alexander Kanavin @ 2019-04-03 10:38 UTC (permalink / raw)
To: Burton, Ross
Cc: Adrian Bunk, Tom Rini,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
Just to make clear, the AUH workflow does require the maintainer to
sign off and edit a commit message via 'git commit -s --reset-author
--amend' for every commit, so AUH does not get in the way of useful
commit messages.
Alex
On Wed, 3 Apr 2019 at 12:31, Burton, Ross <ross.burton@intel.com> wrote:
>
> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
>
> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-03 10:38 ` Alexander Kanavin
0 siblings, 0 replies; 55+ messages in thread
From: Alexander Kanavin @ 2019-04-03 10:38 UTC (permalink / raw)
To: Burton, Ross
Cc: Adrian Bunk, Tom Rini,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, yocto
Just to make clear, the AUH workflow does require the maintainer to
sign off and edit a commit message via 'git commit -s --reset-author
--amend' for every commit, so AUH does not get in the way of useful
commit messages.
Alex
On Wed, 3 Apr 2019 at 12:31, Burton, Ross <ross.burton@intel.com> wrote:
>
> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
>
> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] [oe] Git commit process question.
2019-04-03 10:38 ` [oe] " Alexander Kanavin
(?)
@ 2019-04-03 11:38 ` akuster808
-1 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-03 11:38 UTC (permalink / raw)
To: Alexander Kanavin, Burton, Ross
Cc: Tom Rini, Patches and discussions about the oe-core layer, yocto,
OpenEmbedded Devel List, Adrian Bunk
On 4/3/19 3:38 AM, Alexander Kanavin wrote:
> Just to make clear, the AUH workflow does require the maintainer to
> sign off and edit a commit message via 'git commit -s --reset-author
> --amend' for every commit,
Not sure if this a requirement anymore. Most of my packages got updated
by other folks this time around. Hard to say if the AUH played a part
or are folks now using the devtool check.
> so AUH does not get in the way of useful
> commit messages.
There was talk of using the AUH to fast track updates that pass the
process so in that case the message would be whatever the AUH provides
- armin
>
> Alex
>
> On Wed, 3 Apr 2019 at 12:31, Burton, Ross <ross.burton@intel.com> wrote:
>> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
>> pr
>>>> The kernel does not have "upgrade foo to the latest upstream version" commits.
>>>>
>>>> With the Automatic Upgrade Helper this is a semi-automatic task, and
>>>> most of the time there is no specific motivation other than upgrading
>>>> to the latest upstream version.
>>> But since that's just filling in a template the body can also be a
>>> template perhaps with useful AUH data (run at ... by ... ?) ?
>> Apart from making the commit message longer what does this achieve?
>> The commit already has a timestamp and author.
>>
>> Ross
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [oe] Git commit process question.
@ 2019-04-03 11:38 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-03 11:38 UTC (permalink / raw)
To: Alexander Kanavin, Burton, Ross
Cc: Tom Rini, Patches and discussions about the oe-core layer, yocto,
OpenEmbedded Devel List, Adrian Bunk
On 4/3/19 3:38 AM, Alexander Kanavin wrote:
> Just to make clear, the AUH workflow does require the maintainer to
> sign off and edit a commit message via 'git commit -s --reset-author
> --amend' for every commit,
Not sure if this a requirement anymore. Most of my packages got updated
by other folks this time around. Hard to say if the AUH played a part
or are folks now using the devtool check.
> so AUH does not get in the way of useful
> commit messages.
There was talk of using the AUH to fast track updates that pass the
process so in that case the message would be whatever the AUH provides
- armin
>
> Alex
>
> On Wed, 3 Apr 2019 at 12:31, Burton, Ross <ross.burton@intel.com> wrote:
>> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
>> pr
>>>> The kernel does not have "upgrade foo to the latest upstream version" commits.
>>>>
>>>> With the Automatic Upgrade Helper this is a semi-automatic task, and
>>>> most of the time there is no specific motivation other than upgrading
>>>> to the latest upstream version.
>>> But since that's just filling in a template the body can also be a
>>> template perhaps with useful AUH data (run at ... by ... ?) ?
>> Apart from making the commit message longer what does this achieve?
>> The commit already has a timestamp and author.
>>
>> Ross
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [OE-core] Git commit process question.
@ 2019-04-03 11:38 ` akuster808
0 siblings, 0 replies; 55+ messages in thread
From: akuster808 @ 2019-04-03 11:38 UTC (permalink / raw)
To: Alexander Kanavin, Burton, Ross
Cc: Tom Rini, Patches and discussions about the oe-core layer, yocto,
OpenEmbedded Devel List, Adrian Bunk
On 4/3/19 3:38 AM, Alexander Kanavin wrote:
> Just to make clear, the AUH workflow does require the maintainer to
> sign off and edit a commit message via 'git commit -s --reset-author
> --amend' for every commit,
Not sure if this a requirement anymore. Most of my packages got updated
by other folks this time around. Hard to say if the AUH played a part
or are folks now using the devtool check.
> so AUH does not get in the way of useful
> commit messages.
There was talk of using the AUH to fast track updates that pass the
process so in that case the message would be whatever the AUH provides
- armin
>
> Alex
>
> On Wed, 3 Apr 2019 at 12:31, Burton, Ross <ross.burton@intel.com> wrote:
>> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
>> pr
>>>> The kernel does not have "upgrade foo to the latest upstream version" commits.
>>>>
>>>> With the Automatic Upgrade Helper this is a semi-automatic task, and
>>>> most of the time there is no specific motivation other than upgrading
>>>> to the latest upstream version.
>>> But since that's just filling in a template the body can also be a
>>> template perhaps with useful AUH data (run at ... by ... ?) ?
>> Apart from making the commit message longer what does this achieve?
>> The commit already has a timestamp and author.
>>
>> Ross
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-03 10:30 ` [oe] " Burton, Ross
(?)
@ 2019-04-03 14:41 ` Tom Rini
-1 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-03 14:41 UTC (permalink / raw)
To: Burton, Ross
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Adrian Bunk
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
updates are a form of "trivial update" that every project has. "Update
$X from version $Y to $Z" is what a human would normally put. It's
weird looking at git log of nothing but subject+signed-off-by. I'm not
going to object further on this point, but I don't get it.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-03 14:41 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-03 14:41 UTC (permalink / raw)
To: Burton, Ross
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Adrian Bunk
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
updates are a form of "trivial update" that every project has. "Update
$X from version $Y to $Z" is what a human would normally put. It's
weird looking at git log of nothing but subject+signed-off-by. I'm not
going to object further on this point, but I don't get it.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-03 14:41 ` Tom Rini
0 siblings, 0 replies; 55+ messages in thread
From: Tom Rini @ 2019-04-03 14:41 UTC (permalink / raw)
To: Burton, Ross
Cc: yocto, Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Adrian Bunk
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
updates are a form of "trivial update" that every project has. "Update
$X from version $Y to $Z" is what a human would normally put. It's
weird looking at git log of nothing but subject+signed-off-by. I'm not
going to object further on this point, but I don't get it.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-03 14:41 ` [oe] " Tom Rini
(?)
@ 2019-04-03 16:46 ` Khem Raj
-1 siblings, 0 replies; 55+ messages in thread
From: Khem Raj @ 2019-04-03 16:46 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List, Adrian Bunk,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > > >
> > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > most of the time there is no specific motivation other than upgrading
> > > > to the latest upstream version.
> > >
> > > But since that's just filling in a template the body can also be a
> > > template perhaps with useful AUH data (run at ... by ... ?) ?
> >
> > Apart from making the commit message longer what does this achieve?
> > The commit already has a timestamp and author.
>
> It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> updates are a form of "trivial update" that every project has. "Update
> $X from version $Y to $Z" is what a human would normally put. It's
> weird looking at git log of nothing but subject+signed-off-by. I'm not
> going to object further on this point, but I don't get it.
if the content of subject is being repeated in body then I would
prefer an empty body
redundant information in commits should be avoided since it can create
impression that body does not have
useful information and skip reading it. We should strive to make commits
concise and useful.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] Git commit process question.
@ 2019-04-03 16:46 ` Khem Raj
0 siblings, 0 replies; 55+ messages in thread
From: Khem Raj @ 2019-04-03 16:46 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List, Adrian Bunk,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > > >
> > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > most of the time there is no specific motivation other than upgrading
> > > > to the latest upstream version.
> > >
> > > But since that's just filling in a template the body can also be a
> > > template perhaps with useful AUH data (run at ... by ... ?) ?
> >
> > Apart from making the commit message longer what does this achieve?
> > The commit already has a timestamp and author.
>
> It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> updates are a form of "trivial update" that every project has. "Update
> $X from version $Y to $Z" is what a human would normally put. It's
> weird looking at git log of nothing but subject+signed-off-by. I'm not
> going to object further on this point, but I don't get it.
if the content of subject is being repeated in body then I would
prefer an empty body
redundant information in commits should be avoided since it can create
impression that body does not have
useful information and skip reading it. We should strive to make commits
concise and useful.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] Git commit process question.
@ 2019-04-03 16:46 ` Khem Raj
0 siblings, 0 replies; 55+ messages in thread
From: Khem Raj @ 2019-04-03 16:46 UTC (permalink / raw)
To: Tom Rini
Cc: yocto, OpenEmbedded Devel List, Adrian Bunk,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > The kernel does not have "upgrade foo to the latest upstream version" commits.
> > > >
> > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > most of the time there is no specific motivation other than upgrading
> > > > to the latest upstream version.
> > >
> > > But since that's just filling in a template the body can also be a
> > > template perhaps with useful AUH data (run at ... by ... ?) ?
> >
> > Apart from making the commit message longer what does this achieve?
> > The commit already has a timestamp and author.
>
> It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> updates are a form of "trivial update" that every project has. "Update
> $X from version $Y to $Z" is what a human would normally put. It's
> weird looking at git log of nothing but subject+signed-off-by. I'm not
> going to object further on this point, but I don't get it.
if the content of subject is being repeated in body then I would
prefer an empty body
redundant information in commits should be avoided since it can create
impression that body does not have
useful information and skip reading it. We should strive to make commits
concise and useful.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-03 16:46 ` [oe] " Khem Raj
(?)
@ 2019-04-03 23:07 ` Paul Eggleton
-1 siblings, 0 replies; 55+ messages in thread
From: Paul Eggleton @ 2019-04-03 23:07 UTC (permalink / raw)
To: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
Cc: Tom Rini, Adrian Bunk
On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > version" commits.
> > > > >
> > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > most of the time there is no specific motivation other than
> > > > > upgrading
> > > > > to the latest upstream version.
> > > >
> > > > But since that's just filling in a template the body can also be a
> > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > >
> > > Apart from making the commit message longer what does this achieve?
> > > The commit already has a timestamp and author.
> >
> > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> > updates are a form of "trivial update" that every project has. "Update
> > $X from version $Y to $Z" is what a human would normally put. It's
> > weird looking at git log of nothing but subject+signed-off-by. I'm not
> > going to object further on this point, but I don't get it.
>
> if the content of subject is being repeated in body then I would
> prefer an empty body
> redundant information in commits should be avoided since it can create
> impression that body does not have
> useful information and skip reading it. We should strive to make commits
> concise and useful.
There is often (I won't say always, but often) something useful you can put in
the commit message. If it's a recipe upgrade, you could put a pointer to the
upstream changelog in it, for example. As the person doing the upgrade if your
prior review of that changelog or other upstream release documentation
indicated any backwards-compatibility issues or CVEs fixed then those really
ought to be mentioned as well; if you're feeling especially generous you might
mention highlights of any new functionality. (I have a proposal that might
help us automate part of that which I've not yet fully fleshed out, hopefully
one day soon I will get around to it.)
The issue of empty commit messages is something I've complained about in the
past, and not just about recipe upgrades. If I - as someone who is relatively
familiar with OE - have to actually read beyond the shortlog / commit message
to understand the basics of why a change has been made, then it's likely that
the commit message wasn't good enough. Unlike other issues, once a commit goes
in the message is set in stone within the git history, so if you are working
on a change, *please* take a minute or two to document it adequately in the
commit message so that others looking back can understand it.
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [oe] Git commit process question.
@ 2019-04-03 23:07 ` Paul Eggleton
0 siblings, 0 replies; 55+ messages in thread
From: Paul Eggleton @ 2019-04-03 23:07 UTC (permalink / raw)
To: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
Cc: Tom Rini, Adrian Bunk
On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > version" commits.
> > > > >
> > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > most of the time there is no specific motivation other than
> > > > > upgrading
> > > > > to the latest upstream version.
> > > >
> > > > But since that's just filling in a template the body can also be a
> > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > >
> > > Apart from making the commit message longer what does this achieve?
> > > The commit already has a timestamp and author.
> >
> > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> > updates are a form of "trivial update" that every project has. "Update
> > $X from version $Y to $Z" is what a human would normally put. It's
> > weird looking at git log of nothing but subject+signed-off-by. I'm not
> > going to object further on this point, but I don't get it.
>
> if the content of subject is being repeated in body then I would
> prefer an empty body
> redundant information in commits should be avoided since it can create
> impression that body does not have
> useful information and skip reading it. We should strive to make commits
> concise and useful.
There is often (I won't say always, but often) something useful you can put in
the commit message. If it's a recipe upgrade, you could put a pointer to the
upstream changelog in it, for example. As the person doing the upgrade if your
prior review of that changelog or other upstream release documentation
indicated any backwards-compatibility issues or CVEs fixed then those really
ought to be mentioned as well; if you're feeling especially generous you might
mention highlights of any new functionality. (I have a proposal that might
help us automate part of that which I've not yet fully fleshed out, hopefully
one day soon I will get around to it.)
The issue of empty commit messages is something I've complained about in the
past, and not just about recipe upgrades. If I - as someone who is relatively
familiar with OE - have to actually read beyond the shortlog / commit message
to understand the basics of why a change has been made, then it's likely that
the commit message wasn't good enough. Unlike other issues, once a commit goes
in the message is set in stone within the git history, so if you are working
on a change, *please* take a minute or two to document it adequately in the
commit message so that others looking back can understand it.
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [OE-core] Git commit process question.
@ 2019-04-03 23:07 ` Paul Eggleton
0 siblings, 0 replies; 55+ messages in thread
From: Paul Eggleton @ 2019-04-03 23:07 UTC (permalink / raw)
To: yocto, OpenEmbedded Devel List,
Patches and discussions about the oe-core layer
Cc: Tom Rini, Adrian Bunk
On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > version" commits.
> > > > >
> > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > most of the time there is no specific motivation other than
> > > > > upgrading
> > > > > to the latest upstream version.
> > > >
> > > > But since that's just filling in a template the body can also be a
> > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > >
> > > Apart from making the commit message longer what does this achieve?
> > > The commit already has a timestamp and author.
> >
> > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> > updates are a form of "trivial update" that every project has. "Update
> > $X from version $Y to $Z" is what a human would normally put. It's
> > weird looking at git log of nothing but subject+signed-off-by. I'm not
> > going to object further on this point, but I don't get it.
>
> if the content of subject is being repeated in body then I would
> prefer an empty body
> redundant information in commits should be avoided since it can create
> impression that body does not have
> useful information and skip reading it. We should strive to make commits
> concise and useful.
There is often (I won't say always, but often) something useful you can put in
the commit message. If it's a recipe upgrade, you could put a pointer to the
upstream changelog in it, for example. As the person doing the upgrade if your
prior review of that changelog or other upstream release documentation
indicated any backwards-compatibility issues or CVEs fixed then those really
ought to be mentioned as well; if you're feeling especially generous you might
mention highlights of any new functionality. (I have a proposal that might
help us automate part of that which I've not yet fully fleshed out, hopefully
one day soon I will get around to it.)
The issue of empty commit messages is something I've complained about in the
past, and not just about recipe upgrades. If I - as someone who is relatively
familiar with OE - have to actually read beyond the shortlog / commit message
to understand the basics of why a change has been made, then it's likely that
the commit message wasn't good enough. Unlike other issues, once a commit goes
in the message is set in stone within the git history, so if you are working
on a change, *please* take a minute or two to document it adequately in the
commit message so that others looking back can understand it.
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [oe] [OE-core] Git commit process question.
2019-04-03 23:07 ` [yocto] [oe] " Paul Eggleton
(?)
@ 2019-04-04 0:38 ` Khem Raj
-1 siblings, 0 replies; 55+ messages in thread
From: Khem Raj @ 2019-04-04 0:38 UTC (permalink / raw)
To: Paul Eggleton
Cc: Yocto Project, Adrian Bunk, OpenEmbedded Devel List, Tom Rini,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>
> On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > > version" commits.
> > > > > >
> > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > > most of the time there is no specific motivation other than
> > > > > > upgrading
> > > > > > to the latest upstream version.
> > > > >
> > > > > But since that's just filling in a template the body can also be a
> > > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > > >
> > > > Apart from making the commit message longer what does this achieve?
> > > > The commit already has a timestamp and author.
> > >
> > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> > > updates are a form of "trivial update" that every project has. "Update
> > > $X from version $Y to $Z" is what a human would normally put. It's
> > > weird looking at git log of nothing but subject+signed-off-by. I'm not
> > > going to object further on this point, but I don't get it.
> >
> > if the content of subject is being repeated in body then I would
> > prefer an empty body
> > redundant information in commits should be avoided since it can create
> > impression that body does not have
> > useful information and skip reading it. We should strive to make commits
> > concise and useful.
>
> There is often (I won't say always, but often) something useful you can put in
> the commit message. If it's a recipe upgrade, you could put a pointer to the
> upstream changelog in it, for example. As the person doing the upgrade if your
> prior review of that changelog or other upstream release documentation
> indicated any backwards-compatibility issues or CVEs fixed then those really
> ought to be mentioned as well; if you're feeling especially generous you might
> mention highlights of any new functionality. (I have a proposal that might
> help us automate part of that which I've not yet fully fleshed out, hopefully
> one day soon I will get around to it.)
>
> The issue of empty commit messages is something I've complained about in the
> past, and not just about recipe upgrades. If I - as someone who is relatively
> familiar with OE - have to actually read beyond the shortlog / commit message
> to understand the basics of why a change has been made, then it's likely that
> the commit message wasn't good enough. Unlike other issues, once a commit goes
> in the message is set in stone within the git history, so if you are working
> on a change, *please* take a minute or two to document it adequately in the
> commit message so that others looking back can understand it.
>
Definitely, and I agree that we should put relevant information in
commits, usually
the information about side effects if any, links to changelog etc. are
useful too
however, we should not enforce a behavior which could result in
redundancy as explained
> Thanks,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [oe] Git commit process question.
@ 2019-04-04 0:38 ` Khem Raj
0 siblings, 0 replies; 55+ messages in thread
From: Khem Raj @ 2019-04-04 0:38 UTC (permalink / raw)
To: Paul Eggleton
Cc: Yocto Project, Adrian Bunk, OpenEmbedded Devel List, Tom Rini,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>
> On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > > version" commits.
> > > > > >
> > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > > most of the time there is no specific motivation other than
> > > > > > upgrading
> > > > > > to the latest upstream version.
> > > > >
> > > > > But since that's just filling in a template the body can also be a
> > > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > > >
> > > > Apart from making the commit message longer what does this achieve?
> > > > The commit already has a timestamp and author.
> > >
> > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> > > updates are a form of "trivial update" that every project has. "Update
> > > $X from version $Y to $Z" is what a human would normally put. It's
> > > weird looking at git log of nothing but subject+signed-off-by. I'm not
> > > going to object further on this point, but I don't get it.
> >
> > if the content of subject is being repeated in body then I would
> > prefer an empty body
> > redundant information in commits should be avoided since it can create
> > impression that body does not have
> > useful information and skip reading it. We should strive to make commits
> > concise and useful.
>
> There is often (I won't say always, but often) something useful you can put in
> the commit message. If it's a recipe upgrade, you could put a pointer to the
> upstream changelog in it, for example. As the person doing the upgrade if your
> prior review of that changelog or other upstream release documentation
> indicated any backwards-compatibility issues or CVEs fixed then those really
> ought to be mentioned as well; if you're feeling especially generous you might
> mention highlights of any new functionality. (I have a proposal that might
> help us automate part of that which I've not yet fully fleshed out, hopefully
> one day soon I will get around to it.)
>
> The issue of empty commit messages is something I've complained about in the
> past, and not just about recipe upgrades. If I - as someone who is relatively
> familiar with OE - have to actually read beyond the shortlog / commit message
> to understand the basics of why a change has been made, then it's likely that
> the commit message wasn't good enough. Unlike other issues, once a commit goes
> in the message is set in stone within the git history, so if you are working
> on a change, *please* take a minute or two to document it adequately in the
> commit message so that others looking back can understand it.
>
Definitely, and I agree that we should put relevant information in
commits, usually
the information about side effects if any, links to changelog etc. are
useful too
however, we should not enforce a behavior which could result in
redundancy as explained
> Thanks,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [OE-core] Git commit process question.
@ 2019-04-04 0:38 ` Khem Raj
0 siblings, 0 replies; 55+ messages in thread
From: Khem Raj @ 2019-04-04 0:38 UTC (permalink / raw)
To: Paul Eggleton
Cc: Yocto Project, Adrian Bunk, OpenEmbedded Devel List, Tom Rini,
Patches and discussions about the oe-core layer
On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>
> On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini <trini@konsulko.com> wrote:
> > > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > > version" commits.
> > > > > >
> > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > > most of the time there is no specific motivation other than
> > > > > > upgrading
> > > > > > to the latest upstream version.
> > > > >
> > > > > But since that's just filling in a template the body can also be a
> > > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > > >
> > > > Apart from making the commit message longer what does this achieve?
> > > > The commit already has a timestamp and author.
> > >
> > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH
> > > updates are a form of "trivial update" that every project has. "Update
> > > $X from version $Y to $Z" is what a human would normally put. It's
> > > weird looking at git log of nothing but subject+signed-off-by. I'm not
> > > going to object further on this point, but I don't get it.
> >
> > if the content of subject is being repeated in body then I would
> > prefer an empty body
> > redundant information in commits should be avoided since it can create
> > impression that body does not have
> > useful information and skip reading it. We should strive to make commits
> > concise and useful.
>
> There is often (I won't say always, but often) something useful you can put in
> the commit message. If it's a recipe upgrade, you could put a pointer to the
> upstream changelog in it, for example. As the person doing the upgrade if your
> prior review of that changelog or other upstream release documentation
> indicated any backwards-compatibility issues or CVEs fixed then those really
> ought to be mentioned as well; if you're feeling especially generous you might
> mention highlights of any new functionality. (I have a proposal that might
> help us automate part of that which I've not yet fully fleshed out, hopefully
> one day soon I will get around to it.)
>
> The issue of empty commit messages is something I've complained about in the
> past, and not just about recipe upgrades. If I - as someone who is relatively
> familiar with OE - have to actually read beyond the shortlog / commit message
> to understand the basics of why a change has been made, then it's likely that
> the commit message wasn't good enough. Unlike other issues, once a commit goes
> in the message is set in stone within the git history, so if you are working
> on a change, *please* take a minute or two to document it adequately in the
> commit message so that others looking back can understand it.
>
Definitely, and I agree that we should put relevant information in
commits, usually
the information about side effects if any, links to changelog etc. are
useful too
however, we should not enforce a behavior which could result in
redundancy as explained
> Thanks,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] [oe] Git commit process question.
2019-04-04 0:38 ` [yocto] [oe] " Khem Raj
(?)
@ 2019-04-04 10:50 ` Alexander Kanavin
-1 siblings, 0 replies; 55+ messages in thread
From: Alexander Kanavin @ 2019-04-04 10:50 UTC (permalink / raw)
To: Khem Raj
Cc: Tom Rini, Paul Eggleton,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Yocto Project, Adrian Bunk
On Thu, 4 Apr 2019 at 02:39, Khem Raj <raj.khem@gmail.com> wrote:
> Definitely, and I agree that we should put relevant information in
> commits, usually
> the information about side effects if any, links to changelog etc. are
> useful too
> however, we should not enforce a behavior which could result in
> redundancy as explained
To be honest, researching changelogs and summarizing them into commit
messages is feasible if you maintain maybe three recipes. When you
maintain thirty, it becomes a burden, and I am not going to take that
burden. There's already enough work in getting the upgrade into
working shape, work that largely goes unnoticed and unappreciated and
does not require finding and reading upstream changelogs.
HOWEVER. I think we could start putting links to changelogs into the
recipes themselves. If it's a webpage, we can use templating to
substitute version numbers, if it's a file in the source tree, we can
also come up with a format for that. Then it's a simple extension to
e.g. devtool to show that changelog via less or a browser.
Alex
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [yocto] [oe] Git commit process question.
@ 2019-04-04 10:50 ` Alexander Kanavin
0 siblings, 0 replies; 55+ messages in thread
From: Alexander Kanavin @ 2019-04-04 10:50 UTC (permalink / raw)
To: Khem Raj
Cc: Tom Rini, Paul Eggleton,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Yocto Project, Adrian Bunk
On Thu, 4 Apr 2019 at 02:39, Khem Raj <raj.khem@gmail.com> wrote:
> Definitely, and I agree that we should put relevant information in
> commits, usually
> the information about side effects if any, links to changelog etc. are
> useful too
> however, we should not enforce a behavior which could result in
> redundancy as explained
To be honest, researching changelogs and summarizing them into commit
messages is feasible if you maintain maybe three recipes. When you
maintain thirty, it becomes a burden, and I am not going to take that
burden. There's already enough work in getting the upgrade into
working shape, work that largely goes unnoticed and unappreciated and
does not require finding and reading upstream changelogs.
HOWEVER. I think we could start putting links to changelogs into the
recipes themselves. If it's a webpage, we can use templating to
substitute version numbers, if it's a file in the source tree, we can
also come up with a format for that. Then it's a simple extension to
e.g. devtool to show that changelog via less or a browser.
Alex
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [OE-core] [yocto] Git commit process question.
@ 2019-04-04 10:50 ` Alexander Kanavin
0 siblings, 0 replies; 55+ messages in thread
From: Alexander Kanavin @ 2019-04-04 10:50 UTC (permalink / raw)
To: Khem Raj
Cc: Tom Rini, Paul Eggleton,
Patches and discussions about the oe-core layer,
OpenEmbedded Devel List, Yocto Project, Adrian Bunk
On Thu, 4 Apr 2019 at 02:39, Khem Raj <raj.khem@gmail.com> wrote:
> Definitely, and I agree that we should put relevant information in
> commits, usually
> the information about side effects if any, links to changelog etc. are
> useful too
> however, we should not enforce a behavior which could result in
> redundancy as explained
To be honest, researching changelogs and summarizing them into commit
messages is feasible if you maintain maybe three recipes. When you
maintain thirty, it becomes a burden, and I am not going to take that
burden. There's already enough work in getting the upgrade into
working shape, work that largely goes unnoticed and unappreciated and
does not require finding and reading upstream changelogs.
HOWEVER. I think we could start putting links to changelogs into the
recipes themselves. If it's a webpage, we can use templating to
substitute version numbers, if it's a file in the source tree, we can
also come up with a format for that. Then it's a simple extension to
e.g. devtool to show that changelog via less or a browser.
Alex
^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2019-04-04 10:50 UTC | newest]
Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-01 22:33 Git commit process question akuster808
2019-04-01 23:02 ` [OE-core] " Richard Purdie
2019-04-01 23:02 ` Richard Purdie
2019-04-01 23:20 ` [OE-core] " akuster808
2019-04-01 23:20 ` akuster808
2019-04-01 23:20 ` akuster808
2019-04-01 23:41 ` [OE-core] " Mark Hatle
2019-04-01 23:41 ` Mark Hatle
2019-04-02 4:45 ` [OE-core] " Jon Mason
2019-04-02 4:45 ` Jon Mason
2019-04-02 4:45 ` Jon Mason
2019-04-02 19:47 ` [OE-core] " Tom Rini
2019-04-02 19:47 ` Tom Rini
2019-04-02 21:24 ` [oe] [OE-core] " akuster808
2019-04-02 21:24 ` akuster808
2019-04-02 21:24 ` [oe] " akuster808
2019-04-03 0:45 ` [oe] [OE-core] " Tom Rini
2019-04-03 0:45 ` Tom Rini
2019-04-03 0:45 ` [oe] " Tom Rini
2019-04-03 3:51 ` [oe] [OE-core] " Jon Mason
2019-04-03 3:51 ` Jon Mason
2019-04-03 3:51 ` [oe] " Jon Mason
2019-04-02 6:51 ` [OE-core] " Adrian Bunk
2019-04-02 6:51 ` Adrian Bunk
2019-04-02 19:46 ` [OE-core] " Tom Rini
2019-04-02 19:46 ` Tom Rini
2019-04-02 19:46 ` Tom Rini
2019-04-02 20:58 ` [OE-core] " akuster808
2019-04-02 20:58 ` akuster808
2019-04-03 9:34 ` [OE-core] " Adrian Bunk
2019-04-03 9:34 ` Adrian Bunk
2019-04-03 10:30 ` [oe] [OE-core] " Burton, Ross
2019-04-03 10:30 ` Burton, Ross
2019-04-03 10:30 ` [oe] " Burton, Ross
2019-04-03 10:38 ` [OE-core] " Alexander Kanavin
2019-04-03 10:38 ` [OE-core] " Alexander Kanavin
2019-04-03 10:38 ` [oe] " Alexander Kanavin
2019-04-03 11:38 ` [OE-core] " akuster808
2019-04-03 11:38 ` [yocto] [OE-core] " akuster808
2019-04-03 11:38 ` [yocto] [oe] " akuster808
2019-04-03 14:41 ` [oe] [OE-core] " Tom Rini
2019-04-03 14:41 ` Tom Rini
2019-04-03 14:41 ` [oe] " Tom Rini
2019-04-03 16:46 ` [oe] [OE-core] " Khem Raj
2019-04-03 16:46 ` Khem Raj
2019-04-03 16:46 ` [oe] " Khem Raj
2019-04-03 23:07 ` [oe] [OE-core] " Paul Eggleton
2019-04-03 23:07 ` [yocto] " Paul Eggleton
2019-04-03 23:07 ` [yocto] [oe] " Paul Eggleton
2019-04-04 0:38 ` [oe] [OE-core] " Khem Raj
2019-04-04 0:38 ` [yocto] " Khem Raj
2019-04-04 0:38 ` [yocto] [oe] " Khem Raj
2019-04-04 10:50 ` [OE-core] " Alexander Kanavin
2019-04-04 10:50 ` [OE-core] [yocto] " Alexander Kanavin
2019-04-04 10:50 ` [yocto] [oe] " Alexander Kanavin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.