On 9/12/2014 8:07 am, Gedare Bloom wrote:
On Mon, Dec 8, 2014 at 3:52 PM, Chris Johns <chr...@rtems.org> wrote:
On 8/12/2014 5:48 pm, Sebastian Huber wrote:
This makes the report reproducible.
I think the report should include a date. I do not see any advantage having
reproducible reports. The report captures the specific instance of the
build.
Would it make sense to re-build on a different date and want to
compare the results to see there is no difference?
What you build on a different date cannot be the same by definition.
The date has changed. In a quality context if you reference the first
build that is what you have. You cannot reference an initial build and
then say you used a subsequent build because you know it is the same.
Where is the dated report to say they are same ? The report is about
reporting what you did and what happened.
Maybe a flag can be turned on/off for "reproducible" builds.
I do not like flags being available for things like this. The user then
needs to audit the setting and this moves the compliance back up to the
user.
Or is it the user's
responsibility to strip out such non-reproducible bits if they want
such a feature?
I can understand an MD5 hash on the components built and that result
being in a report. I have never tried to see if a repeat build of the
tools produces an exact binary image.
I can also understand a user explicitly adding an exemption to an audit
process not to check the report. For example it is common to see target
binary images have exemptions for date and time strings embedded in them
and a manual audit with a hex dump to verify this is the only difference.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
