Evgeny Kotkov via dev wrote on Sun, Jan 29, 2023 at 16:37:20 +0300:
> Daniel Shahaf <d...@daniel.shahaf.name> writes:
>
> > > (I'm not saying that the above rules have to be used in this particular
> > > case
> > > and that a veto is invalid, but still thought it’s worth mentioning.)
> > >
> >
> > I vetoed the change because it hadn't been designed on the dev@ list,
> > had not garnered dev@'s consensus, and was being railroaded through.
> > (as far as I could tell)
>
> I have *absolutely* no idea where "being railroaded through" comes from.
> Really, it's a wrong way of portraying and thinking about the events that have
> happened so far.
>
> Reiterating over those events: I wrote an email containing my thoughts
> and explaining the motivation for such change. I didn't reply to some of
> the questions (including some tricky questions, such as the one featuring
> a theoretical hash function), because they have been at least partly
> answered by others in the thread, and I didn't have anything valuable
> to add at that time.
>
> During that time, I was actively coding the core part of the change,
> to check if it's possible technically. Which is important, as far as
> I believe, because not all theoretically possible solutions can be implemented
> without facing significant practical or implementation-related issues, and
> it seems to me that you significantly undervalue such an approach.
>
Quoting myself from elsethread: [3]
- 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.
> I do not say my actions were exemplary, but as far as I can tell, they're
> pretty much in line with how svn-dev has been operating so far. But, it all
> resulted in an unclear veto without any _technical_ arguments, where what's
> being vetoed is unclear as well, because the change was not ready at the
> moment veto got casted.
>
Look, it's pretty simple. You said "We should do Y because it
addresses X". You didn't explain why X needs to be addressed, didn't
consider what alternatives there are to Y, didn't consider any cons that
Y may have… and when people had questions, you just began to
implement Y, without responding to or even acknowledging those
questions.
That's not how design discussions work. A design discussion doesn't go
"state decision; state pros; implement"; it goes "state problem; discuss
potential solutions, pros, cons; decide; implement" (cf. [4, 5, 6]).
That's why I called veto: not because I considered any particular
proposal then on the table unreasonable, but because I considered /the
decision process being used/ unreasonable (cf. [7]).
> And because your veto goes in favor of a specific process
Yes, I'm arguing in favour of first defining a problem, then considering
solutions to it, both their pros and cons, and only then deciding what
to implement. This process isn't unique, novel, or singular; it's
standard in multiple disciplines [4–7].
> (considering that
> no other arguments were given), the only thing that's *actually* being
> railroaded is an odd form of an RTC (review-then-commit) process that is
> against our usual CTR (commit-then-review) [1,2]. That's railroading,
> because it hasn't been explicitly discussed anywhere and a consensus
> on it has not been reached.
This thread was started on 2022-12-20 [1], with the idiomatic
"Thoughts?" sign-off. The first relevant code was committed on
2023-01-19 [2].
That is: the change followed RTC to begin with. Considering that both
[1] and [2] were authored by you personally, I find it difficult to
charitably interpret your claim that "an odd form of [RTC]" was being
"railroaded", as RTC rather than "our usual CTR [process]" was being
followed at your own decision.
It's perhaps worth pointing out the veto followed the branch creation
because that was the point when I gave up on waiting for someone to
respond to the objections that had been made by then. It wasn't a veto
on using a branch, as I have clarified: [3]
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.
So, no, I wasn't advocating /either/ RTC or CTR; I was advocating that
the "R" step happen at all. A branch may take place before, during, or
after discussion — see [3] for more — but the important thing is that
discussion happen. The OP doesn't have to agree with all points made,
but doesn't get to ignore them and proceed as though they have never
been posted.
Daniel
[1]
https://mail-archives.apache.org/mod_mbox/subversion-dev/202212.mbox/%3CCAP_GPNh2erpHzP0umxV_MuZRXKCkW_n8gJEGsM4aafqcKk02RQ%40mail.gmail.com%3E
[2] r1906817
[3]
https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3C20230121092231.GA3174%40tarpaulin.shahaf.local2%3E
[4] https://skybrary.aero/articles/dec
[5] http://paulgraham.com/essay.html under the second and third headings
[6] https://xyproblem.info/
[7] the Business Judgment Rule
