[PATCH 1/6] Remove build date from first page

[Chris Johns]

> On 8 Jan 2019, at 5:19 pm, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> 
>> On 08/01/2019 02:59, Chris Johns wrote:
>>> On 7/1/19 11:30 pm, Sebastian Huber wrote:
>>>> On 07/01/2019 12:49, Sebastian Huber wrote:
>>>> On 07/01/2019 12:39, Chris Johns wrote:
>>>>>> On 7 Jan 2019, at 10:03 pm, Sebastian Huber
>>>>>> <sebastian.huber at embedded-brains.de> wrote:
>>>>>> 
>>>>>> The usage of a build date prevents reproducible builds.
>>>>> -1
>>>>> 
>>>>> I prefer a build date being present. For unreleased it marks the online
>>>>> builds and for releases it tags the day built.
>>>> Adding the Git commit to the documents would be more useful. The build date is
>>>> completely arbitrary.
>>> What do you think about replacing the date with a Git commit hash? I can try to
>>> do this.
>>> 
>> For branch builds this is OK and I am happy to see it added and for releases we
>> also need to have the release details.
>> 
>> Technically a hash is all that is needed so it is correct if you need to
>> determined the exact source used but is this what people expect with
>> documentation, ie is a date expected?
>> 
>> The catalog holds the build date which is shown if you point a browser at the
>> documentation. Our online page has this.
>> 
>> If the users and community are OK with no date in the documentation then I am
>> OK. I am still not sure how repeatable builds of docs can be made because of the
>> dependence on so many other parts that can vary. I also do not know how you
>> perform the comparison on a PDF.
> 
> What about the Git commit hash and the check in date of the commit?

That is a good idea. The catalogue can still have the build date and the PDF has the creation date in it’s properties. 

Chris