Shawn H Corey writes:
> On 2024-03-15 14:38, Russ Allbery wrote:
>> If you would be happy with a PR to remove that bullet point, we're just
>> vigorously agreeing. Otherwise, I'm not sure what you're asking for
>> instead.
> I guess I wasn't clear. I was talking about making the requirement
Karen Etheridge writes:
> I believe the paragraph in the docs should stay, but change the MUST to
> a SHOULD, with a proviso that there should be a way to disable it (for
> the purposes of repeatable builds etc). If the paragraph is removed
> entirely, no one will implement it (the fact that it
On Wed, Mar 20, 2024, at 18:34, Karen Etheridge wrote:
> I believe the paragraph in the docs should stay, but change the MUST to a
> SHOULD, with a proviso that there should be a way to disable it (for the
> purposes of repeatable builds etc). If the paragraph is removed entirely, no
> one
On Wed, Mar 20, 2024 at 2:28 AM Graham Knop wrote:
> On Fri, Mar 15, 2024 at 7:55 PM Shawn H Corey wro
> I guess I wasn't clear. I was talking about making the requirement an
> option for the formatters. When the user runs a formatter, they can specify
> an option to include the info in their
On Fri, Mar 15, 2024 at 7:55 PM Shawn H Corey wrote:
>
> On 2024-03-15 14:38, Russ Allbery wrote:
>
> If you would be happy with a PR to remove that bullet point, we're just
> vigorously agreeing. Otherwise, I'm not sure what you're asking for
> instead.
>
>
> I guess I wasn't clear. I was
On Fri, Mar 15, 2024 at 08:43:08AM -0700, Russ Allbery wrote:
> Does anyone want to make an argument for keeping this in the spec? If
> not, I'm going to submit a PR to Perl to remove this whole bullet point.
> (The note about including errors as comments is not wrong, but I don't
> think it
On 2024-03-15 14:38, Russ Allbery wrote:
If you would be happy with a PR to remove that bullet point, we're just
vigorously agreeing. Otherwise, I'm not sure what you're asking for
instead.
I guess I wasn't clear. I was talking about making the requirement an
option for the formatters.
Shawn H Corey writes:
> On 2024-03-15 12:44, Russ Allbery wrote:
>> Shawn H Corey writes:
>>> I think it should be an option. Sometimes it is necessary to know that
>>> a change in appearance is caused by changes to a module and not to the
>>> generating document.
>> Do we need to explicitly
On 2024-03-15 12:44, Russ Allbery wrote:
Shawn H Corey writes:
I think it should be an option. Sometimes it is necessary to know that a
change in appearance is caused by changes to a module and not to the
generating document.
Do we need to explicitly state that it's an option, or would
Shawn H Corey writes:
> I think it should be an option. Sometimes it is necessary to know that a
> change in appearance is caused by changes to a module and not to the
> generating document.
Do we need to explicitly state that it's an option, or would removing the
requirement to always do it
On 2024-03-15 11:43, Russ Allbery wrote:
perlpodspec currently contains the following note on POD processor
implementations:
I think it should be an option. Sometimes it is necessary to know that a
change in appearance is caused by changes to a module and not to the
generating document.
perlpodspec currently contains the following note on POD processor
implementations:
• When rendering Pod to a format that allows comments (i.e., to nearly
any format other than plaintext), a Pod formatter must insert comment
text identifying its name and version number, and the name and
12 matches
Mail list logo
