So it's accurate to say that "Reproducible Builds has standardized" that since they only talk about their own organization, not that it has been accepted to IETF or something like that.
Something being “standardised” requires more than just a specification and just because the specification throws the term “standard” around it doesn’t mean it has been formally standardised.
This doesn’t mean people shouldn’t still follow the specification. Plenty of specifications exist that have not been standardised. For example, there is an RFC specification for CSVs but not formal standard.
So by all means push this specification as a de facto standard but please don’t mislead people saying it has been standardised when it has not.
There’s nothing wrong with a specification or even a reference implementation but they are not themselves standards. And that’s exactly what this is: a widely respected specification.
You shouldn’t have to lie about this being standardised for it still to be relevant.
I hate arguing semantics because it’s usually a worthless argument. But the problem here is people are specifically arguing that Reproducible Builds have standardised something when they have not. If you still want to use their specification then that’s grand. You don’t need a specification standardised for it to be relevant.
However on the very specific point of whether this is a standard, I’m yet to see any proof that anyone has actually standardised the specification. All I’m reading is “but they say it is” and frankly that’s not enough to make a standard.
Of course not, and no one has claimed that this is a globally recognized standard. The only thing that has been claimed is that they have standarized it for _themselves_.
It's important to get semantics right, and it's equally important to really read and understand what's being said, and not assume something "more" is being said than what is really said.
> > Reproducible Builds has standardized "SOURCE_DATE_EPOCH" for exactly this usecase.
> It's important to get semantics right, and it's equally important to really read and understand what's being said
I’d say either you’re wrong or the GP was unclear in his statement. Either way I don’t buy your attempt to shift the responsibility of error into me.
However, a couple hundred projects heed this standard along with most distributions. Does your nitpicking really matter?
If your comment wasn’t so rude from the outset then I wouldn’t have nitpicked your statement. I think there’s some “law” people often quite about people who correct other people that applies to your post.
Yes there is
> Who would be the root standards authority to appoint other standards authorities?
You’re thinking of signing authorities.
> And why can't the Reproducible Builds project be one of them?
You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work.
Anyway, I’ll make this my last post on the subject. I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference.
> You’re thinking of signing authorities.
No, I don't. I was asking for a list of authorities that you would consider authoritative (which invariably will be subjective, but would be interesting nonetheless).
> You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work.
Oh sure, specifications always suck™. But that is unfortunately quite independent from the organisation, happens all the time with ISO standards, IETF RFCs, or whatever you would consider "recognised" bodies.
> I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference.
You haven't explained anything. All you have been saying in this thread is "I don't recognise the Reproducible Builds project as a standards authority, because I only believe in my personal list of authorities that I won't reveal".
The point is, a standard does not become a standard because it is published by a "competent authority". A standard becomes a standard when people in the respective field converge on using it.
And yes, there are of course certain fields where this convergence can be enforced e.g. through local law, professional associations etc. However, software development is generally not one of these fields: who will reprimand you if you write a C compiler that does not follow ISO/IEC 9899, or in this case one that does not respect SOURCE_DATE_EPOCH?
https://reproducible-builds.org/docs/source-date-epoch/