[rb-general] [PATCH] Document timestamp clamping

[Daniel Kahn Gillmor]

On Fri 2016-11-04 12:53:19 -0400, Holger Levsen wrote:
> On Fri, Nov 04, 2016 at 10:32:37AM -0400, Daniel Kahn Gillmor wrote:
>> I think clamping is the right thing to do, which means i think the spec
>> is currently wrong.  We should fix it.  Just because it's a rare case
>> doesn't mean it should be ignored.
>
> I must say that the logic of these two paragraphs sounds very
> compelling. I'm not fully convinced yet, that clamping is right and the
> spec is wrong though. Can you summarize clamping in one simple sentence?

Sure:

+			Where build processes embed timestamps that are not
+			"current", but are somehow related to the source and
+			the build processes, they MUST use a timestamp no later
+			than <envar>SOURCE_DATE_EPOCH</envar>.


But you knew i was going to say that, right? :P

Even "simpler" if you want that, would be to re-cast the entire spec as
a clamping spec, since "current" is just a special case of clamping:

    Everywhere that the build process records a timestamp, that
    timestamp should be no greater than SOURCE_DATE_EPOCH.

but if you want to acknowledge nuance, you have to add a parenthetical
aside:

    ... records a timestamp (that is not intended to be "in the
    future"), ...

This is because some software is distributed with specific timestamps
that are relevant to the future -- for example, a certain feature might
sunset on a certain day, or perhaps the software contains a table of
astronomical events.

And of course, in practice, there are intermediate build systems that
absolutely do need to distinguish between timestamps happening *during
build* (e.g. make) that would be disastrous if we set them all to
SOURCE_DATE_EPOCH.  So we probably should change "records a timestamp"
to "records a timestamp that will be distributed in the generated binary
artifact".

With yet more nuance, we might also want to say that we expect
SOURCE_DATE_EPOCH itself to be no later than the actual current time --
that is, we don't expect someone in 2016 to build a package with a
SOURCE_DATE_EPOCH in 2020.  These specs will fall apart and fail to
provide reproducibility in that case.

I'm sure there are phrasings that are better than these feeble attempts,
though.  I welcome alternative proposals.

        --dkg