On Mon, Sep 25, 2023 at 14:03:26 +0200, Ulrich Mueller wrote:
> > On Sun, 24 Sep 2023, Jonas Stein wrote:
>
> >> # Removal on 2023-10-21. Bug #667687, #667689.
>
> > We should use "after" instead of "on":
>
> > # Removal after T
>
> I wonder if we even need to specify the wording in such d
> On Sun, 24 Sep 2023, Jonas Stein wrote:
>> # Removal on 2023-10-21. Bug #667687, #667689.
> We should use "after" instead of "on":
> # Removal after T
I wonder if we even need to specify the wording in such detail. For any
tools parsing the file, it might be enough to say that the line m
Hi all,
# Removal on 2023-10-21. Bug #667687, #667689.
We should use "after" instead of "on":
# Removal after T
--
Best,
Jonas
OpenPGP_signature.asc
Description: OpenPGP digital signature
Hi all,
I want to suggest a standard format for profiles/package.mask, for
multiple reasons:
Sounds sensible. +1
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.
> On Sat, 23 Sep 2023, Alex Boag-Munroe wrote:
> I'm confused, you're against adding "massive header blocks" but you're
> fine with Arthur's 9 line entry but not my 8 line one.
Your 8 line entry was this (please correct me if you meant to refer to
an entry from a different message):
--- 8< -
On Sat, 23 Sept 2023 at 08:03, Ulrich Mueller wrote:
> This seems rather restrictive, adds unnecessary redundancy, and would
> make it hard to type an entry without the aid of special tools.
>
> Also, there are other files like use.mask which probably shouldn't have
> a completely different forma
Arthur Zamarin writes:
> [[PGP Signed Part:Undecided]]
> On 22/09/2023 17.50, Alex Boag-Munroe wrote:
>> On Fri, 22 Sept 2023 at 15:37, Sam James wrote:
>>>
>>>
>>> Alex Boag-Munroe writes:
>>>
Any reason for the parseable parts to not be in an established human
readable/editable fo
Ulrich Mueller writes:
> [[PGP Signed Part:Undecided]]
>> On Fri, 22 Sep 2023, Alex Boag-Munroe wrote:
>
>> Perhaps eventually it could/should be used for the whole file but as
>> an interim/beginning there's no reason you couldn't start with
>> comments:
>
>> # [PREAMBLE]
>> # Timestamp: 2
> On Fri, 22 Sep 2023, Alex Boag-Munroe wrote:
> Perhaps eventually it could/should be used for the whole file but as
> an interim/beginning there's no reason you couldn't start with
> comments:
> # [PREAMBLE]
> # Timestamp: 2023-09-21 15:07:42+00:00
> # Author: Arthur Zamarin
> # Justificat
On 22/09/2023 17.50, Alex Boag-Munroe wrote:
> On Fri, 22 Sept 2023 at 15:37, Sam James wrote:
>>
>>
>> Alex Boag-Munroe writes:
>>
>>> Any reason for the parseable parts to not be in an established human
>>> readable/editable format? e.g. the config ini style format, or TOML?
>>
>> The only issu
On Fri, 22 Sept 2023 at 15:37, Sam James wrote:
>
>
> Alex Boag-Munroe writes:
>
> > Any reason for the parseable parts to not be in an established human
> > readable/editable format? e.g. the config ini style format, or TOML?
>
> The only issue really is that depending on how it's done (do we do
Alex Boag-Munroe writes:
> Any reason for the parseable parts to not be in an established human
> readable/editable format? e.g. the config ini style format, or TOML?
The only issue really is that depending on how it's done (do we do
it for the whole file, or just comments), it may need a new
Any reason for the parseable parts to not be in an established human
readable/editable format? e.g. the config ini style format, or TOML?
To crib from the OP example with something configparser understands:
[PREAMBLE]
Timestamp: 2023-09-21 15:07:42+00:00
Author: Arthur Zamarin
Justification: Very
Ulrich Mueller writes:
>> On Fri, 22 Sep 2023, Ulrich Mueller wrote:
>
>> On Fri, 22 Sep 2023, Florian Schmaus wrote:
>>> Some, including me, consider timestamps without timezone specifiers to
>>> be in local time (either of the consumer or producer of the
>>> timestamp). Hence, if you
> On Fri, 22 Sep 2023, Ulrich Mueller wrote:
> On Fri, 22 Sep 2023, Florian Schmaus wrote:
>> Some, including me, consider timestamps without timezone specifiers to
>> be in local time (either of the consumer or producer of the
>> timestamp). Hence, if you really must have UTC here, then a
Hi,
On 2023/09/22 13:16, Florian Schmaus wrote:
On 21/09/2023 21.40, Arthur Zamarin wrote:
If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list
FWIW, I would assume the last-rite date to be the date wher
On 21/09/2023 21.40, Arthur Zamarin wrote:
If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list
FWIW, I would assume the last-rite date to be the date where the
package's last rites where initiated, i.e.,
> On Fri, 22 Sep 2023, Florian Schmaus wrote:
> Some, including me, consider timestamps without timezone specifiers to
> be in local time (either of the consumer or producer of the
> timestamp). Hence, if you really must have UTC here, then at least
> consider making it explicit my requiring t
On 22/09/2023 08.39, Florian Schmaus wrote:
Some, including me, consider timestamps without timezone specifiers to
be in local time (either of the consumer or producer of the timestamp).
Hence, if you really must have UTC here, then at least consider making
it explicit my requiring the 'Z' time
On 21/09/2023 23.48, Sam James wrote:
Ulrich Mueller writes:
On Thu, 21 Sep 2023, Florian Schmaus wrote:
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.
Ulrich Mueller writes:
> [[PGP Signed Part:Undecided]]
>> On Thu, 21 Sep 2023, Florian Schmaus wrote:
>
>>> The first line of the "#"-prefixed explanation block must be of the
>>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>>> format -MM-DD, in UTC timezone.
> On Thu, 21 Sep 2023, Florian Schmaus wrote:
>> The first line of the "#"-prefixed explanation block must be of the
>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>> format -MM-DD, in UTC timezone.
>
> Can we drop this? Or,
On 21/09/2023 21.40, Arthur Zamarin wrote:
Hi all
I want to suggest a standard format for profiles/package.mask, for
multiple reasons:
Sounds sensible. +1
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is
23 matches
Mail list logo
