> (FWIW, maintaining the remove-log-addressing branch doesn't count, and
> frankly I have a hard time imagining how that branch could be less buggy
> than trunk, given that it's received far less attention and testing.)
As you should know, current FSFS code on trunk is like this:
if (log_addressing_enabled(rev))
{
do_one();
}
else
{
do_else();
}
And this covers *all* cases, because FSFS code supports reading and
*writing* all previous FSFS formats. I've just removed do_one() calls on
remove-log-addressing branch. How this could be more buggy?? Please
provide more details about this point.
> You must have forgotten the history of ra_serf: almost nobody used it
> until we made it the default and only option, and so we only started
> getting useful feedback after the 1.8.0 release.
We release features not just to get a 'useful feedback' from the users.
There was a lot of work to prepare ra_serf to be the default option. I guess
we would have a different kind of feedback if this work have not been done.
>> Moreover, we have discussed
>> this on Berlin 2013 hackathon [1]:
>> [[[
>> stefan2 expressed that while he is confident that FSFSv7 is solid code,
>> it's also quite critical and could easily take a year or more to fully
>> stabilize. Attendees felt that perhaps it would be best to introduce FSFSv7
>> as a new, experimental fs-type. Stefan said he had been thinking
>> about the same thing himself, even considering a different name for
>> his implementation.
>> ]]]
> Yup, we did; more than a year ago. A lot has changed since then.
What exactly have changed and where it was discussed?
> I'll even go as far as to suspect that you're not aware there's no revprop
> caching on trunk right now.
Should I suspect that you are saying this to make it seem that I don't have
any technical ground behind my position?
As I said elsethread, I routinely read everyone's commits to Subversion
codebase (with different level of attention, of course). Moreover, both
problems that caused to disable revprop caching on trunk were initially
found by two of my colleagues. So, despite the fact that I've been on
vacation when r1619774 was committed, I obviously know the story.
Also, I do not see yours '+1' or other kind of positive feedback regarding
the revprop-caching-ng branch.
Have you got a chance to review the revprop-caching-ng branch?
Do you agree with all the significant technical solutions adopted in
this branch?
--
Ivan Zhakov
Received on 2014-09-08 18:24:54 CEST