Den lör 13 jan. 2024 kl 00:50 skrev Johan Corveleyn <jcor...@gmail.com>:
> 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 ... > I agree with Johan on this. The long hiatus is unfortunate. But it won't help to point fingers at this point. > > ... > > 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. > I also agree with this. >From what I remember of the dicsussions earlier there were concerns that a changed file might go undetected if someone change it to another file with a collision with the original file. I think that might be a vaild point, especially if we don't have the pristine files anymore. I'd also like to understand why we need the multi-checksum format instead of just plainly switching to XXX (insert favourite checksuming algorithm here). Does it help us to have multiple types of checksums available? Would we use BOTH as a resort (likelyhood of collision in SHA1 and in XXX at the same time approaching zero)? Does it help backwards/forwards compatibility? Kind regards, Daniel Sahlberg
