To be clear, I wasn't vetoing changing the hash algorithm. I was vetoing making a change without discussion. If there is discussion and it results in consensus to change the algorithm, that'll be absolutely fine by me.
Daniel Karl Fogel wrote on Sat, 21 Jan 2023 17:58 +00:00: > *nod* This issue isn't important enough to me to continue the > conversation -- I'd like for new hash algorithms to be possible, > and I think Evgeny's work on it is worthwhile, but I don't feel > nearly as strongly about this as I feel about making the new > pristineless working copies available in an official release as > soon as we can. > > Best regards, > -Karl > > On 21 Jan 2023, Daniel Shahaf wrote: >>Karl Fogel wrote on Fri, Jan 20, 2023 at 11:09:11 -0600: >>> On 20 Jan 2023, Daniel Shahaf wrote: >>> > Evgeny Kotkov via dev wrote on Thu, 19 Jan 2023 18:52 +00:00: >>> > > I can complete the work on this branch and bring it to a >>> > > production-ready >>> > > state, assuming there are no objections. >>> > >>> > Your assumption is counterfactual: >>> > >>> > https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3C20230119152001.GA27446%40tarpaulin.shahaf.local2%3E >>> > >>> > https://mail-archives.apache.org/mod_mbox/subversion-dev/202212.mbox/%3CCAMHy98NqYBLZaTL5-FAbf24RR6bagPN1npC5gsZenewZb0-EuQ%40mail.gmail.com%3E >>> > >>> > Objections have been raised, been left unanswered, and now >>> > implementation work has commenced following the original >>> > design. That's >>> > not acceptable. >>> >>> I'm a little surprised by your reaction. >>> >>> It is never "not acceptable" for someone to do implementation >>> work on a >>> branch while a discussion is happening, even if that discussion >>> contains >>> objections to or questions about the premise of the branch >>> work. >>> >>> It's a branch. He didn't merge it to trunk, and he posted it >>> as an explicit >>> invitation for discussion. >>> >> >>I didn't object to the use of a branch /per se/. I objected to >>the >>treating of objections that *had already been posted* as though >>they had >>never been posted. *That's* not acceptable. >> >>However, since you ask, I don't think implementing a proposal on >>a branch is necessarily a good idea: >> >>- If the branch is seen and presented as a PoC for furthering >>discussion >> and for discovering practical considerations (e.g., that >> PRISTINE.MD5_CHECKSUM docstring I found yesterday during >> discussion, >> or the ra_serf sha1 optimization that anyone implementing the >> branch >> would run into), it's likely a good thing. >> >>- On the other hand, when the branch implements the original >>proposal, >> whilst outstanding questions were not only not answered but >> also not >> acknowledged, that's quite another thing. It can result in: >> >> + The branch maintainer being biased in favour of the approach >> they >> have implemented. (People tend not to argue against what >> they have >> expended resources on. Cf. plan continuation bias, sunk cost >> fallacy.) >> >> + dev@ being biased towards the approach that has been >> implemented >> (because it's a known entity; because no one is volunteering >> to >> implement another approach; because there's a desire to cut >> a minor release soon…). This, in turn, can result in… >> >> + …an incentive for participants *not* to hold open design >> discussions on dev@ in the first place. >> >>> > I'm vetoing the change until a non-rubber-stamp design >>> > discussion has been completed on the public dev@ list. >>> >>> Starting an implementation on a branch is a valuable >>> contribution to a >>> design discussion -- it's exactly the kind of >>> "non-rubber-stamp" >>> contribution one would want. >>> >> >>You're just repeating what you said above. >> >>> If you want to re-iterate points you've made that have been >>> left unanswered, >>> that would be a useful contribution -- perhaps some of those >>> points will be >>> updated now that there's actual code, or perhaps they won't. >>> Either way, >>> what Evgeny is doing here seems very constructive to me, and >>> entirely within >>> the normal range of how we do things. >> >>Posting a paragraph such as the one I'm replying to is not >>"entirely >>within the normal range of how we do things". As to my points, >>see >><https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3C20230119152001.GA27446%40tarpaulin.shahaf.local2%3E>. >>They boil down to this: >> >> <alice> We should migrate away from SHA-1. >> <bob> Why? >> >>Daniel >> >>> Best regards, >>> -Karl
