On Fri, Jan 12, 2024 at 12:37 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: ... > 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.
I agree, but obviously the hibernation is not some deliberate action by anyone. It's just that most of us here have less spare time for dev@ discussions (and for SVN development) than before. Especially for such complex matters, and especially when people feel there are walking into a minefield. There are only a few active devs left, and tuits are running low ... ... > 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. It has become more clear to me (I was only following tangentially) that your veto is focused on the development methodology and the lack of design discussion. Is that a valid reason for a veto? We are low on resources, someone still finds time to make some progress, no one blocks it on technical grounds, and then someone vetoes it because we don't have enough resources? That puts us pretty much in deadlock, because we are too low on resources. Or maybe I misunderstand? To be clear: I appreciate your input, Daniel, and your insistence on a more thorough design discussion. I assume it's coming from a genuine concern that we formulate problems well, and think hard about possible solutions (focusing on the precise problem we are trying to solve). But at the end of the day, if that design discussion doesn't happen (or not enough to your satisfaction anyway), is that grounds for a veto? For me it's a tough call, because on the one hand you have a point, but on the other hand ... you're blocking _some_ progress because the process behind it is not perfect (which is hard to do with the 3.25 tuits we have left). > 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"? I agree that would be a good step. I too find it a bit unclear what problem we're actually trying to solve, apart from a vague feeling that SHA-1 will become more and more broken over time, and that this will cause fatal injury to SVN (in its WC, protocol, dump format, or repository). And perhaps the fact that security auditors are becoming more and more triggered by seeing SHA-1 (even if they don't understand the way it is used and its ramifications). Making it possible to 'svn add' SHA-1 collisions is not it, I think. -- Johan
