On 7 November 2014 03:00, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Nov 6, 2014 at 2:07 PM, Ben Reser <ben_at_reser.org> wrote:
>>
>> On 11/6/14 8:44 AM, Greg Stein wrote:
[...]
>> That said, given the ambiguity of our policy situation here I'm not
>> inclined to
>> try and "fix" any sort of failure on our part to follow such a policy now.
>>
>> Ironically, this policy is now working counter to the intent. The intent
>> was
>> to try to keep problematic code off trunk until it was ready. To avoid a
>> scenario like the move tracking issues we ran into leading into 1.8.0.
>> Now
>> we've got issues with fsfs7, that at least to me seem to be more
>> procedural
>> than technical.
>>
>> IMNSHO I'd much rather have technical issues than be tied up in procedural
>> limbo. Which is precisely where we are right now with 1.9.
>
>
> I haven't been able to pay enough attention to Subversion over the past
> months :-( ... what is this "procedural limbo"?
>
> In my mind, we have code. Start the release process. If it gets (3) +1 votes
> for release, then it goes out the door. Pretty simple. Is it just that some
> people don't want Feature A in that release? They better find a
> good/technical reason to veto, then. And that will only pause it, until the
> problem is resolved.
>
> If people think Feature A hasn't had enough testing, then they should do the
> testing to show they are right. "serf as default" languished for years
> because of naysayers. Philip did some great work to demonstrate specific
> problems, and so we kept serf as optional. When those all got fixed, we
> flipped the bit.
>
Actually, I have used my veto on the log addressing feature two months ago [1].
Also I proposed to implement major FSFS performance related changes in
the experimental FSX format that also going to be released in Subversion 1.9.
The full log-addressing feature story with detailed explanation of my
technical reasons is given in the same thread [2].
The problem is that there is a very narrow interpretation of 'technical
reasons' for a veto. I'm repeatedly being asked to demonstrate a very
particular exploit for the vetoed code. And it's repeatedly said that my
veto is invalid if I can't demonstrate such exploit. Other technical reasons
such as code duplication and unproportional maintenance burden doesn't
even count as technical ones. The discussion happened five months ago in [3].
> Forward progress is the goal. To *hold back* change, then you must veto.
>
I agree with that goal but not at the cost of possible massive data
corruptions in upgraded repositories. "There will always be bugs" ((c) brane),
but we are currently *ripping out the revprop caching feature in the patch
release*! [4]. The log addressing feature is in the same area, it is designed
and implemented in the same way, it is not reversible because it changes the
FSFS data format. What are the reasons to be optimistic and endlessly assume
that there will be no of data corruption because nobody can find the particular
exploit right now?
I still strongly believe that we should not release the log-addressing feature
in the 1.9 release. We should not make it the default option for all the
upgraded repositories, at least. This is my position as a full-committer and
PMC member. I'm just doing my best and try to use all the available and
acceptable means to defend my position.
[1] http://svn.haxx.se/dev/archive-2014-08/0298.shtml
[2] http://svn.haxx.se/dev/archive-2014-09/0079.shtml
[3] http://svn.haxx.se/dev/archive-2014-05/0145.shtml
[4] http://svn.haxx.se/dev/archive-2014-08/0273.shtml
--
Ivan Zhakov
Received on 2014-11-07 14:08:43 CET