On 7 November 2014 03:00, Greg Stein <gst...@gmail.com> wrote: > On Thu, Nov 6, 2014 at 2:07 PM, Ben Reser <b...@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
