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 YYYY-MM-DD, in UTC timezone.
Can we drop this? Or, at least, relax this.
I usually just enter my locale date here and like to avoid having to
think about that UTC is potentially in a different date. I also can
not remember any situation where the date being in UTC matters. Plus,
if you want accurate timestamps, then the git commit/author date is
here for you. :)
[[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 YYYY-MM-DD, in UTC timezone.
Can we drop this? Or, at least, relax this.
I think UTC makes a lot of sense in an international context like ours.
It also avoids flapping of the date between entries (i.e. a newer entry having an older date than the previous one).
I usually just enter my locale date here and like to avoid having to
think about that UTC is potentially in a different date. I also can
not remember any situation where the date being in UTC matters. Plus,
if you want accurate timestamps, then the git commit/author date is
here for you. :)
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 the 'Z' timezone specifier
(which, if you want to be ISO compatible, probably means that the
timestamp must include HH:MM too).
On Fri, 22 Sep 2023, Ulrich Mueller wrote:
Some, including me, consider timestamps without timezone specifiers toOn Fri, 22 Sep 2023, Florian Schmaus wrote:
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' timezone specifier
(which, if you want to be ISO compatible, probably means that the
timestamp must include HH:MM too).
How about converting package.mask to XML? The xs:date type would allow
a date followed by a time zone [1].
/me hides
On Fri, 22 Sep 2023, Ulrich Mueller wrote:
Some, including me, consider timestamps without timezone specifiers toOn Fri, 22 Sep 2023, Florian Schmaus wrote:
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' timezone specifier
(which, if you want to be ISO compatible, probably means that the
timestamp must include HH:MM too).
How about converting package.mask to XML? The xs:date type would allow
a date followed by a time zone [1].
/me hides
Seriously, this isn't a hill I am willing to die on. I still prefer UTC there, but I'd be fine if the wording said "should" instead of "must".
Ulrich
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 <arthurzam@gentoo.org>
Justification: Very broken, no idea why packaged, need to drop ASAP.
The project is done with supporting this package.
Bugs: 667687, 667689
Removal Date: 2023-10-21
Packages: dev-lang/python
The format is well documented already and simple to check for
validity, so any GLEP would just need to cover correct keys/values.
Just a thought.
Alex Boag-Munroe <ninpo@qap.la> 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 (profile)
EAPI which will take a while to implement and deploy.
If it's just for comments, then we can do it immediately though.
To crib from the OP example with something configparser understands: [PREAMBLE]
Timestamp: 2023-09-21 15:07:42+00:00
Author: Arthur Zamarin <arthurzam@gentoo.org>
Justification: Very broken, no idea why packaged, need to drop ASAP.
The project is done with supporting this package.
Bugs: 667687, 667689
Removal Date: 2023-10-21
Packages: dev-lang/python
The format is well documented already and simple to check for
validity, so any GLEP would just need to cover correct keys/values.
But yeah, I agree it's worth thinking about a proper format rather than fragile text mangling going into the future.
On Fri, 22 Sept 2023 at 15:37, Sam James <sam@gentoo.org> wrote:
Perhaps eventually it could/should be used for the whole file but as
Alex Boag-Munroe <ninpo@qap.la> 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 (profile)
EAPI which will take a while to implement and deploy.
If it's just for comments, then we can do it immediately though.
To crib from the OP example with something configparser understands:
[PREAMBLE]
Timestamp: 2023-09-21 15:07:42+00:00
Author: Arthur Zamarin <arthurzam@gentoo.org>
Justification: Very broken, no idea why packaged, need to drop ASAP.
The project is done with supporting this package.
Bugs: 667687, 667689
Removal Date: 2023-10-21
Packages: dev-lang/python
The format is well documented already and simple to check for
validity, so any GLEP would just need to cover correct keys/values.
But yeah, I agree it's worth thinking about a proper format rather than
fragile text mangling going into the future.
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 <arthurzam@gentoo.org>
# Justification: Very broken, no idea why packaged, need to drop ASAP.
# The project is done with supporting this package.
# Bugs: 667687, 667689
# Packages: dev-lang/python
dev-lang/python
This simply adds a pre parse step of stripping the comments then
feeding directly into configparser or probably more suitable, TOML
since TOML has better syntax for directly delivering things like a "Packages:" key as a list.
Redoing a bunch of package.* parsing probably wasn't in scope of the
OP but I've always wondered and this felt an opportune moment to
ask/suggest :)
--
Ninpo
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 <arthurzam@gentoo.org>
# Justification: Very broken, no idea why packaged, need to drop ASAP.
# The project is done with supporting this package.
# Bugs: 667687, 667689
# Packages: dev-lang/python
dev-lang/python
[[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: 2023-09-21 15:07:42+00:00
# Author: Arthur Zamarin <arthurzam@gentoo.org>
# Justification: Very broken, no idea why packaged, need to drop ASAP.
# The project is done with supporting this package.
# Bugs: 667687, 667689
# Packages: dev-lang/python
dev-lang/python
And I thought my suggestion to use XML was far-fetched and an obvious
joke. :(
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 format. Their entries often have the author/date
line plus a one line comment which says all that is needed. Adding
massive header blocks there would be excessive.
IMHO Arthur's original proposal was fine. Let's not over-complicate
things.
Ulrich
[[End of PGP Signed Part]]
[[PGP Signed Part:Undecided]]
On 22/09/2023 17.50, Alex Boag-Munroe wrote:
On Fri, 22 Sept 2023 at 15:37, Sam James <sam@gentoo.org> wrote:
Perhaps eventually it could/should be used for the whole file but as
Alex Boag-Munroe <ninpo@qap.la> 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 (profile)
EAPI which will take a while to implement and deploy.
If it's just for comments, then we can do it immediately though.
To crib from the OP example with something configparser understands:
[PREAMBLE]
Timestamp: 2023-09-21 15:07:42+00:00
Author: Arthur Zamarin <arthurzam@gentoo.org>
Justification: Very broken, no idea why packaged, need to drop ASAP.
The project is done with supporting this package.
Bugs: 667687, 667689
Removal Date: 2023-10-21
Packages: dev-lang/python
The format is well documented already and simple to check for
validity, so any GLEP would just need to cover correct keys/values.
But yeah, I agree it's worth thinking about a proper format rather than
fragile text mangling going into the future.
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 <arthurzam@gentoo.org>
# Justification: Very broken, no idea why packaged, need to drop ASAP.
# The project is done with supporting this package.
# Bugs: 667687, 667689
# Packages: dev-lang/python
dev-lang/python
This simply adds a pre parse step of stripping the comments then
feeding directly into configparser or probably more suitable, TOML
since TOML has better syntax for directly delivering things like a
"Packages:" key as a list.
Redoing a bunch of package.* parsing probably wasn't in scope of the
OP but I've always wondered and this felt an opportune moment to
ask/suggest :)
Thanks for the idea. Yes, it was out of scope such suggestions for me originally, but thinking more about it, I take it more positively.
Please let me (and others) to consider it for some days, cause this is
very interesting proposal. Things to consider is how much effort it is
to file in future, which format to use, etc.
--
Ninpo
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 format. Their entries often have the author/date
line plus a one line comment which says all that is needed. Adding
massive header blocks there would be excessive.
IMHO Arthur's original proposal was fine. Let's not over-complicate
things.
Ulrich
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.
My idea was a stop gap to add something easily parsed once the
comments are stripped but keeping the comments in place currently for backwards
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
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 must
contain, in this order:
- "Removal" (case insensitive?) as the first word,
- exactly one date in YYYY-MM-DD format,
- optionally, the word "bug" followed by one or more bug numbers.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 399 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 101:41:54 |
| Calls: | 8,363 |
| Calls today: | 2 |
| Files: | 13,165 |
| Messages: | 5,898,006 |