Evgeny Kotkov via dev wrote on Mon, 29 Dec 2025 18:32 +00:00:
> Evgeny Kotkov <[email protected]> writes:
>
>> From the RM perspective, I propose we proceed with creating the 1.15.x branch
>> shortly, and defer any other outstanding items to 1.16.x. This should allow
>> us to keep our focus and attention on various tasks required for 1.15.0.
>
> To avoid any confusion, my opinion as a PMC member regarding the
> pristine-checksum-salt branch has not changed [2]:
>
> ```
> For the history: thread [1] proposes the pristine-checksum-salt branch
> that adds the infrastructure to support new pristine checksum kinds in the
> working copy and makes a switch to the dynamically-salted SHA1.
>
> From the technical standpoint, I think that it would be better to release
> the first version of the pristines-on-demand feature having this branch
> merged, because now we rely on the checksum comparison to determine if a
> file has changed — and currently it's a checksum kind with known collisions.
>
> At the same time, having that branch merged probably isn't a formal release
> blocker for the pristines-on-demand feature. Also, considering that the
> pristine-checksum-salt branch is currently vetoed by danielsh (presumably,
> for an indefinite period of time), I'd like to note that personally I have
> no objections to proceeding with a release of the pristines-on-demand
> feature without this branch.
> ```
>
Are you referring to that branch which I vetoed because you walked into dev@
with a ready-made design, ignored everyone's input, and then announced you were
starting to implement your original design as there's consensus on it?
My veto there was a rather rare beast: I wasn't vetoing a design decision
("This should use a port number higher than 1024 so it doesn't need to be
launched as uid 0") but a design process, or rather, the lack of /on-list/
/consensus-based/ design process.
That isn't something I can change my mind on; it's Foundation policies. Apache
projects are <rfc21119>REQUIRED</rfc2119> to make decisions through an on-list
consensus process, for any number of reasons, from inclusiveness of people in
different timezones to having a clear audit trail in case of copyright
infringement suits---and as a PMC member, I don't have the luxury of looking
the other way when I notice a breach of that process, or I'd risk having the
corporate veil pierced at me.
To be clear, following the Apache decision-making process is a requirement for
being allowed to use the "Apache®" brand. Neither dev@ nor private@ is
authorized to make decisions other than via the established "consensus of the
dev@ list" process.
Anyway, I'd like to ask Nathan if he'd please champion the veto for me. That
is: I'd like to delegate to Nathan the decision of whether to reäffirm or
withdraw the veto, and more concretely, of when to declare a particular design
draft to be the result of on-list consensus design process. Nathan, you know
the drill: if you say Aye, great and thank you very much; if you say Nay, thank
you very much too and you needn't even give a reason, and I won't ask for a
reason offlist either. Cheers :)
For the record, the veto was cast in the "Re: Switching from SHA1 to a checksum
type without known collisions in 1.15 working copy format" thread on 2023-01-20
and reäffirmed under the same subject line in 2024-01-12. I made a total of
nine posts to that thread in that timeframe, which clarify what I do---and do
not---object to. For instance, quoting myself:
> And once again, for clarity: I'm not vetoing migrating away from SHA-1.
> (In fact, my intuition was that it'd be a good idea.)
Anyway, looking up the dates reminded me we should get started on organizing
the veto's third birthday party. Maybe infra could put up a Puppet show?
Daniel
> At the same time, from the RM perspective, it seems that the best available
> option is to proceed and release the current state. So I intend to move
> forward with that, proceeding towards rolling the RC1 build.
>
> [1]: https://lists.apache.org/thread/xmd7x6bx2mrrbw7k5jr1tdmhhrlr9ljc
> [2]: https://lists.apache.org/thread/7q26dxpd076hl3k6yxx6j7xv3zjppbn0
>
>
> Thanks,
> Evgeny Kotkov
