Den tis 30 dec. 2025 kl 06:03 skrev Daniel Shahaf <[email protected]>:
> 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. > If I understand this correctly, you want to have a discussion about the design of this feature. As I understand the suggestion from Evgeny is to: * Make the WC database support different checksum types, possibly even between different files in the WC. The implementation - which was explicitly stated as a proof of concept to validate that the above idea was even implementable - support SHA1 (as before) and a salted SHA1. Evgeny can probably correct my memory here, it has been a while and I didn't lookup the details. In my mind the above are all valid arguments in the discussion @Daniel: Can you comment on the technical suggestions here? > 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 :) > May I ask why Nathan should have a special voice in this decision? If we should go down the rabbit hole of overturning the veto (and I dug deep into the ASF decision making rules some time ago), this is my understanding: - Vetos can only be cast for technical reasons and they must include a technical argument. The PMC can, with a majority vote, decide if the technical argument is valid or not (which in turn could overthrow the veto). Personally I would hate to go down the road of voting, it would be much better if we can discuss the actual suggestion and resolve any issues. > 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. > Replying to Evgeny's original suggestion: I agree that it would be desirable to switch away from SHA1, but it is not the time to add additional code to the 1.15 release - if we open THAT door, I'd like to bring in the utf-8 work as well. Cheers, Daniel Sahlberg > > > > [1]: https://lists.apache.org/thread/xmd7x6bx2mrrbw7k5jr1tdmhhrlr9ljc > > [2]: https://lists.apache.org/thread/7q26dxpd076hl3k6yxx6j7xv3zjppbn0 > > > > > > Thanks, > > Evgeny Kotkov >
