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
