On 2020-08-14 11:34 +0200, Jean-Baptiste Kempf wrote:
> On Wed, 12 Aug 2020, at 14:38, Alexander Strasser wrote:
> > On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote:
> > > On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> > > > Definitions of non-obvious data should have a short c
On Wed, 12 Aug 2020, at 14:38, Alexander Strasser wrote:
> On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote:
> > On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> > > Definitions of non-obvious data should have a short comment
> > > explaining their origin.
> > >
> > > If t
On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote:
> On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> > Definitions of non-obvious data should have a short comment
> > explaining their origin.
> >
> > If the data is of mathematical origin, you can document that
> > or u
On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> Definitions of non-obvious data should have a short comment
> explaining their origin.
>
> If the data is of mathematical origin, you can document that
> or use code snippets or pseudo-code. If the data was gained
> emp
On 2020-08-09 13:13 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-09):
> > >> Andreas:
[...]
>
> > At least the aspect Mark mentioned below.
> >
> > In general I think it could be worded a bit clearer and easier to grasp.
> > Basically it should ask for a short comment in front of no
lör 2020-08-08 klockan 19:57 +0200 skrev Nicolas George:
> diff --git a/doc/developer.texi b/doc/developer.texi
> index b33cab0fc7..c3103f31dc 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -216,6 +216,14 @@ please use av_log() instead.
> @item
> Casts should be used only when
On Sat, 8 Aug 2020, at 19:57, Nicolas George wrote:
> +@item
> +If the code contains tables of numbers or other data, their origin should be
> +documented in a comment, so that other developers can rebuild them if
> +necessary.
I would add "as honestly as possible" after documented... or something
Zane van Iperen (12020-08-09):
> I'm apprehensive about this, especially in the case of
> reverse-engineered tables. It should definitely be encouraged, but not
> necessarily hard-required.
>
> If you explicitly say "Reverse Engineered from so-and-so", that seems
> essentially like putting a targe
Alexander Strasser (12020-08-09):
> >> Andreas:
>
> I'm sure the following was addressed at me.
Yes, sorry to both of you.
> IMHO we don't actually need ideology for this matter.
I hope so.
> At least the aspect Mark mentioned below.
>
> In general I think it could be worded a bit clearer and
Hi Nicolas!
Am 8. August 2020 23:26:02 MESZ schrieb Mark Thompson :
>On 08/08/2020 18:57, Nicolas George wrote:
[...]
>> Andreas:
I'm sure the following was addressed at me.
>>> Not sure I agree with your definition of Libre Software and your
>exact
>>
>> I was more trying to express the d
On Sat, 8 Aug 2020 19:57:09 +0200
"Nicolas George" wrote:
>
> Tables that were not just written by the code author are
> not actually source code, otherwise,
> "recode data..x1 < proprietary.o > source.c"
> would be enough to launder a proprietary blob into
> the source code.
>
> Documenting th
On 08/08/2020 18:57, Nicolas George wrote:
Tables that were not just written by the code author are
not actually source code, otherwise,
"recode data..x1 < proprietary.o > source.c"
would be enough to launder a proprietary blob into
the source code.
Documenting the origin of the tables or the me
Tables that were not just written by the code author are
not actually source code, otherwise,
"recode data..x1 < proprietary.o > source.c"
would be enough to launder a proprietary blob into
the source code.
Documenting the origin of the tables or the methods
for their generation is necessary to le
13 matches
Mail list logo
