Karl Fogel wrote on Wed, 03 Jan 2024 22:13 +00:00: > On 01 Apr 2023, Evgeny Kotkov via dev wrote: > > Daniel Shahaf <d...@daniel.shahaf.name> writes: > > > > > What's the question or action item to/for me? Thanks. > > > > I'm afraid I don't fully understand your question. As you > > probably remember, the change is blocked by your veto. To my > > knowledge, this veto hasn't been revoked as of now, and I simply > > mentioned that in my email. It is entirely your decision > > whether or not to take any action regarding this matter. > > So AIUI, Evgeny is asking you to withdraw your veto, Daniel. Evgeny would > like to merge this into trunk -- on the grounds, I believe, that it is > strictly an improvement over what we have now, and it opens the door to > further future improvements (each of which would go through the usual > discussion & consensus process, of course).
So, I looked. This thread comprises 237 posts spanning 30 months (July 2021 through today). On 2023-01-20 I cast a veto. There was some activity afterwards, but until the parent post of this one, the thread has been silent for the better part of a year; and now I'm being asked to withdraw my veto. Procedurally, the long hiatus is counterproductive. Neither kfogel nor I had the context in our heads, and the cache misses took their toll in tuits and in wallclock time. Furthermore, I have less spare time for dev@ discussions than I did when I cast the veto (= a year ago next Saturday). Going forward it might be preferable for threads not to hibernate. You didn't link the veto, so I had to go grep for it. It is, presumably, this one: >>>> # Archived-At: >>>> https://mail-archives.apache.org/mod_mbox/subversion-dev/202212.mbox/%3C904aded6-5ef0-4123-ade0-e23a3bb56726%40app.fastmail.com%3E >>>> Date: Fri, 20 Jan 2023 12:15:24 +0000 >>>> From: Daniel Shahaf >>>> To: dev@subversion.apache.org >>>> Subject: Re: Switching from SHA1 to a checksum type without known >>>> collisions in 1.15 working copy format >>>> Message-Id: <904aded6-5ef0-4123-ade0-e23a3bb56...@app.fastmail.com> >>>> >>>> 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 vetoing the change until a non-rubber-stamp design >>>> discussion has been completed on the public dev@ list. So, this veto being in front of me, let me reply to the request that I withdraw it: > So AIUI, Evgeny is asking you to withdraw your veto, Daniel. Evgeny would > like to merge this into trunk -- on the grounds, I believe, that it is > strictly an improvement over what we have now, and it opens the door to > further future improvements (each of which would go through the usual > discussion & consensus process, of course). > > Evgeny's work is on this branch... > > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-salt > > ...which in turn branched from > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-kind. > > I used this command to get an overview of the work: > > $ svn cat > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-salt/BRANCH-README As far as I can tell, the request for veto withdrawal is grounded only in the fact that the veto, whilst in force, prevents the feature branch from being merged/released. The request does not allege the veto was invalid or unfounded in the first place; nor that the veto has /become/ invalid or unfounded due to time having passed; nor that modifications or alterations to the code [or, in this case, to the decision-making process] have been made and are believed to have addressed the veto's grounds. In summary, the request only deals with the fact of a veto and its formal/procedural implications, but does not deal with the substantive justification for the veto at all. That being the case, I have no reason to believe the original grounds of the veto have been addressed. That being the case, I have considered whether merging the feature branch outweighs letting dev@ take a not-only-/pro forma/ role in design discussions. I am of the opinion that it does not, and therefore I reäfirrm the veto. You guys are welcome to try to /convince/ me to change my opinion, or to have the veto invalidated. In either case, you will be more likely to succeed should your arguments relate not only to the veto's implications but also to its /sine qua non/ component: its rationale. Before I salutate this post, I wish to point out that it's rather ironic — or perhaps I should say /alarming/ — that the request for veto withdrawal does not deal with the substantive grounds for the veto, considering those grounds were "dev@ isn't being listened to". In fact, this is so inconsistent with the past 15+ years of kfogel interactions that I feel I should ask whoever happens to live closest to kfogel's if they would be so very kind as to pop over there, knock on the front door, and tell him his email is being impersonated. (Naturally, make sure it's actually him at the door, first. :P) Cheers, Daniel P.S. Could that BRANCH-README please state what's the problem the branch means to solve, i.e., the goal / acceptance test? "Make it possible to «svn add» SHA-1 collisions"? > Evgeny's work is on this branch... > > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-salt > > ...which in turn branched from > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-kind. > > I used this command to get an overview of the work: > > $ svn cat > https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-salt/BRANCH-README > > (The work is several months old now, but for the sake of discussion let's > assume it's mergeable, passes all tests, etc. Obviously, Evgeny's only going > to merge it when all of those conditions are true -- maybe some minor tweaks > will be needed to get it there, I don't know.)
