> On 8 Jan 2019, at 5:19 pm, Sebastian Huber > <sebastian.hu...@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.hu...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
