Update firmware and kernel

[pepijndevos]

Fixes raspberrypi/firmware#1051

[jenkins-ag]

Can one of the admins verify this patch?

[agherzan]

Thanks for your contribution. Everything looks ok functional-wise but we will need to amend a little the commit logs. Can you please do that following http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines instructions? You can find tons of examples in git log.

[agherzan]

@pepijndevos And one more thing: cleanup the merge commit as well (rebase the branch). Thanks once again.

[pepijndevos]

Sorry, I'm working towards a tight deadline, so I don't have the bandwidth to go back and learn a bunch of git fu to clean up the mess at this time. I hope you understand. I can do it properly in a few weeks, but it hardly seems worth it for this trivial change.

[agherzan]

We do consider them worth it @pepijndevos hench why we still adhere to those guidelines. I'll keep this PR open unless we include it in another one.

[pepijndevos]

I woke up with git commands in my head, so there you go.

[agherzan]

@pepijndevos thanks.

[agherzan]

@jenkins-ag ok to test

[agherzan]

Just after approving it I realized you missed the signed of by line.

[pepijndevos]

I give up. It's harder to get the commits right than it's for either of us to increment a version number.

[agherzan]

It's not really as complicated as you think. A simple git log shows you the format in all the past commits and as well I provided detailed information in the documented linked above.

[hhromic]

@agherzan despite not liking the attitude of the author of this PR, maybe we can start suggesting to use git commit -s [...] so git itself adds the signed-off tag automatically in the commit logs. If you agree I can update the guidelines PR accordingly before merging.

Source: https://git-scm.com/docs/git-commit#git-commit--s

[kraj]

@agherzan despite not liking the attitude of the author of this PR, maybe we can start suggesting to use git commit -s [...] so git itself adds the signed-off tag automatically in the commit logs. If you agree I can update the guidelines PR accordingly before merging.

Please do, although this has a downside where we will force people to sign off on
changes which originated elsewhere so make it clear also what SOB means

Source: https://git-scm.com/docs/git-commit#git-commit--s

[pepijndevos]

Ah, so I'm not completely out of my mind. I was under the impression the signed-off tag was a git feature, and that it would happen semi-automatically.

For the record, I do feel kinda bad about not doing the commit properly, and if it were a more substantial change, I'd be a lot more willing to spend time to do it correctly. This PR could have been an issue "hey, firmware is out of date", and it'd take anyone familiar with the project guidelines under a minute to change it. Instead I pushed the code I already had anyway. I wasn't prepared for all this extra bookkeeping.

[agherzan]

@pepijndevos I'm tempted to get into "commit guidelines are not commit size dependent" but I'm sure you know this already. We appreciate and welcome any contribution but they need to adhere, informed or not, to some guidelines to make out life, the maintainers', easier.

@hhromic @kraj It is actually mentioned in the git command examples for creating email patches. And if that is not enough again, the second paragraph in the oe contribution guidelines mention sob and link this requirement to kernel's 5.4 section where this is explained in detail. In anyway, I do get that this looks like annoying metadata and usually when I join an opensource project I have two options:

1. I blindly copy the format of a past commit (and tweak it for my needs) because I don't have the time to dig into all the details of commit guidelines or I don't really care
2. I am truly interested in the project and I dig into details of these guidelines to understand them and compose a well informed commit log

Both are equally OK in my opinion and I don't think that any information in our own documentation would have helped. That being said though, I'm OK in adding as much as possible to try to avoid these kind of discussions.

[pepijndevos]

I definitely fall into the first category. If I'm not deeply involved in a project, the only place I'm likely to read is the readme. Since this is the first project I've ever contributed to with such specific commit guidelines, it might not be a bad idea to put a tldr in the readme.

…

On Sat, 15 Dec 2018, 13:34 Andrei Gherzan ***@***.*** wrote: Merged #356 <#356> into master. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#356 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKSoaVYBAQUlDoZH1Ivsqfk5oIGVufCks5u5OxXgaJpZM4ZPU7O> .