On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton <paul.eggle...@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 <tr...@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 <tr...@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 > > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto