>
>
> In this case testing should be moved out into a separate project,
> unrelated to the artefact being built.
>
> The blunt "no weird binaries in our releases" (because the weird binaries
> are kept outside the releases) is very simple to audit.
>
I don't think moving binaries out into a
On 04/04/2024 14:16, Stefan Bodewig wrote:
On 2024-04-03, Emmanuel Lécharny wrote:
On 02/04/2024 21:57, Nick Wellnhofer wrote:
Binary test data can also be generated with a script or a more sophisticated
test suite which might even be more maintainable in the long run.
On the other
On 2024-04-04, Graham Leggett wrote:
> On 04 Apr 2024, at 09:15, giova...@paclan.it wrote:
>> We might have a similar issue in SpamAssassin, we have code to detect
>> anomalies in .xls and .xlsx files
>> but we do not have any way to create those files (that might contain macros)
>> in the
On 2024-04-03, Emmanuel Lécharny wrote:
> On 02/04/2024 21:57, Nick Wellnhofer wrote:
>> Binary test data can also be generated with a script or a more sophisticated
>> test suite which might even be more maintainable in the long run.
>> On the other hand, tests are the prime target to hide
On 04 Apr 2024, at 09:15, giova...@paclan.it wrote:
> We might have a similar issue in SpamAssassin, we have code to detect
> anomalies in .xls and .xlsx files
> but we do not have any way to create those files (that might contain macros)
> in the build process.
In this case testing should be
On 4/4/24 09:07, Stefan Bodewig wrote:
On 2024-04-02, Nick Wellnhofer wrote:
Binary test data can also be generated with a script or a more
sophisticated test suite which might even be more maintainable in the
long run.
I may be responsible for the majority of binary test data in Commons
On 2024-04-02, Nick Wellnhofer wrote:
> Binary test data can also be generated with a script or a more
> sophisticated test suite which might even be more maintainable in the
> long run.
I may be responsible for the majority of binary test data in Commons
Compress and a lot of it is just there
