Review backlog

Norbert Thiebaud nthiebaud at gmail.com
Sun Aug 16 10:02:58 PDT 2015


On Sun, Aug 16, 2015 at 10:48 AM, Ashod Nakashian <ashnakash at gmail.com> wrote:
> On Sun, Aug 16, 2015 at 1:14 AM, Norbert Thiebaud <nthiebaud at gmail.com>
> wrote:
>>
>> On Sat, Aug 15, 2015 at 6:34 PM, Ashod Nakashian <ashnakash at gmail.com>
>> wrote:
>> >
>> >
>> > In the past I've had a much better response upon submitting patches, so
>> > I'm
>> > inclined to think everyone is busy (which I highly appreciate,) even
>> > though
>> > my patches are closer to 1 month old as I write this.
>>
>> This is summer time... a good chunk of the Devs are on vacation.
>>
>> Now looking at your patches I see 4 of them with _exactly_ the same
>> commit message title.... that is awfully confusing hence the comments
>> you got... I had the same reaction than samuel when I looked at a
>> query of your patches
>
>
> I thought it was a convention to set the commit subject to the bug/feature
> in question.

The (strong) convention is to put the reference to the bug when there
is one, like you did
tdf#nnnn (which btw is one of these : what will help my patch get
reviewed... thing)

In fact you commit message already have all that was needed...
just the pertinent information was relegated on the second line :-)

repeating the summary of the bug report is not necessary, since it is
one click away...
the commit message should thrive to explain what the specific commit in question
is about to help the reviewer and git history browsing -- keeping in
mind that the
bug description 'title', more often than not, bear little relation to
what the bug _really_
is about :-).

And particularly when you have a 'patch series' lie in this case you
absolutely do _not_
want to have the exact same commit message for all the commit of the series
As a reviewer I see these in a list form, and not necessarily in their
logical order.
The typically are presented in order of 'last event on the change-set'.
rebasing them properly and pushing them in the right order can become
very hazardous in that case (as You can noticed with my botched multiple re-base
attempt on your set of 4 patches -- to force a rebuild by jenkins)


Norbert

PS: we, as a project, _do_ lack a well established and agreed upon detailed
formulation of what a good commit message is about..
Right now it is more like: https://en.wikipedia.org/wiki/I_know_it_when_I_see_it


More information about the LibreOffice mailing list