[PATCH 3/9] sb: Do not report current date
Chris Johns
chrisj at rtems.org
Wed Dec 10 03:05:32 UTC 2014
On 9/12/2014 6:00 pm, Sebastian Huber wrote:
>
> On 08/12/14 21:52, Chris Johns 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.
>
> Yes, it captures a specific instance of the build, but why should the
> date be part of it?
An instance is what and when. It has a specific locale and this needs to
be captured.
> What can you do with this date?
It forms part of the record used to create a formal release. If it is
not captured in the report when the tools are built it needs to captured
elsewhere, ie by the user.
>
> My goal is to get rid of anything that is host dependent, e.g. the home
> directory path.
>
The tools built are specific to the that host and so we need to capture
what we need. There is always the possibility things can be removed or
have missed.
The exact configuration of a host is outside the bounds of what we need
to provide.
> If you really want the date, then I omit this patch. For XML report
> however I would like to omit the date nonetheless.
I would like it to remain for the reports.
>
>> The purpose behind the report is to have an output from the process
>> that can feed into a QA audit type process. Part of the purpose of the
>> RTEMS tools is to create an RTEMS Ecosystem and this is about pushing
>> down into RTEMS report generation for these parts of process so users
>> can feed them up into their configuration management system.
>
> My intention to use this report is to add it eventually to the RTEMS
> sources to that you can determine the tool chain that can build exactly
> this RTEMS version. Since the RSB commit is included in the report, you
> can use the RSB in the best case to build the tools. In the worst case
> the report should contain everything that is necessary to build it
> manually.
>
This is different and not the purpose of the report. I am happy
internally we share the code to do this but the report we create and
install when the tools are built needs specific details. This is the
purpose of the report.
I suggest we consider making an sb-source command and add it. This
command can be run to create a suitable configuration file plus fetch
and package all the source and patches without having to run a build
process.
Chris
More information about the devel
mailing list