*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
