On Wed, Sep 2, 2015 at 5:11 PM, Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
wrote:
> Branko Čibej <brane_at_wandisco.com> writes:
>
> > Uh, sorry, you don't get to dictate how the veto gets resolved. Reworking
> > what's on trunk is as valid as reverting. If you don't intend to work on
> the
> > solution, you may as well just let Stefan do that whichever way works
> best
> > for him.
>
> I certainly intend to work on the solution for the problems that I stated
> in my e-mails, but it's a quite difficult task given the amount of changes
> that target these problems, but happen without any prior discussion.
Fair enough. My position on that has two different aspects. First, I think
that the initial commit was well-contained (embracing the stream design
pattern, no server code touched, i.e. no risk of CVEs, explicitly selective
in its application). There was no reason to believe any released
functionality
would be impaired - and it wasn't. So, nothing prompted me to reach out
for feedback beforehand.
The second thing is that I rather prefer exploring a solution in terms of
writing code over speculating about it. Once a patch is available, I find it
much more convenient to review it in the code base than to fiddle through
patch contributions in e-mail. If the necessary change seems complex or
risky, open a branch. This is particularly true in later stages of a release
cycle.
The exploring part becomes particularly attractive when "urgency" is
indicated by raising an issue late Friday night before a long weekend
(Monday was a holiday in the UK) or holidays in general. I then like
to get these things of my plate while at the same time quickly finding
a partner for discussion is difficult. So, that makes just trying to come
up with a fix very attractive.
I am aware that others may prefer e-mail discussions with patches
going back and forth and that's perfectly fine. It's just not my preference.
I'm also pretty sure that you do not purposefully post issues to ruin other
people's time off but it important to know that it does have an effect
on my mode of work. And this is the only reason why I even bring it up.
> This
> has now happened twice — once with r1700305, and the second time with
> r1700799, and I believe that both of these changes contain (other)
> problems.
>
r1700305 is a prime example of what I explained above.
r1700799 is very different. You called my code a mess and asked
for changes to be combined for easy review. That's what you've got.
What other problems do you suspect in r1700799?
>
> The reason why I asked if Stefan could revert the old changes beforehand is
> because otherwise it becomes easy to get lost for anyone who tries to get
> the big picture of what's happening, what we are trying to fix, and how do
> we do that.
>
Honestly, I found the initial "Please revert." rude. An implicit but
nonetheless absolute demand. It can easily be read as "I wont
listen to anything you say until you did as I just told you!" A "I
think we should revert this and look for an alternative solution"
would probably have been much closer to your actual intentions.
I say closer because those are my words not yours.
The second time, you gave at least a rationale (ease of review).
After a few moments of figuring out that all what was needed was
simply a double revert, it has been a matter of minutes to actually
do it - without losing any functionality from my POV. So, I took
that as an annoying but fair request.
After being all explainy in this mail, I'd like to close with something
constructive. Maybe, it would help to prefix "I think stuff is broken"
mails with a simple 1-liner like "[important but not urgent]" or even
"[quick revert needed]". Not as a tag in the subject but just to set
the tone. Then it becomes obvious a solution is needed right away
or if it can easily wait for a week or two.
-- Stefan^2.
Received on 2015-09-05 02:07:04 CEST