From dev-return-40258-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Fri Feb 14 16:06:50 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id EB3A8180647 for ; Fri, 14 Feb 2020 17:06:49 +0100 (CET) Received: (qmail 28872 invoked by uid 500); 14 Feb 2020 16:06:49 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 28860 invoked by uid 99); 14 Feb 2020 16:06:49 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Feb 2020 16:06:49 +0000 Received: from [192.168.1.107] (unknown [81.174.159.228]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 9FBE42234 for ; Fri, 14 Feb 2020 16:06:48 +0000 (UTC) Subject: Re: future of our "experimental" features To: dev@subversion.apache.org References: <20200124115132.GD38254@ted.stsp.name> <20200124143515.GI38254@ted.stsp.name> <4e10c72c-5267-7dae-a937-a95d0086312d@apache.org> <20200212154618.GL19317@ted.stsp.name> From: Julian Foad Message-ID: <2538f508-272c-62cb-6e1c-effa285a472e@apache.org> Date: Fri, 14 Feb 2020 16:06:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200212154618.GL19317@ted.stsp.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Stefan Sperling wrote: > So it sounds like we have consensus on the following: > > * x-wc-copy-mods should simply be moved out of experimental status Although I previously said so in this thread, I am not sure. It should probably be called "wc-diff-and-patch". As a user-level command, I'm sure it has rough edges and lacks complementary features and options that one might wish to find. For example, it probably should support all the "diff" options that make sense and all the "patch" options that make sense. If we had a category of "plumbing" commands (like git does) I'd put it there. It *potentially* has uses as a user-level "porcelain" command, but the reason it is exposed is not primarily for that, rather it's exposed because it exercises two important new plumbing APIs. I'm not really comfortable about adding it in the main UI. As I said before, "it doesn't fit neatly into the existing command-line UI functions and command names". It doesn't feel like this is part of "stabilization". So I suggest to keep it "experimental". > * shelving should be reverted to v1 or hidden at compile- or run-time I can't commit to reverting the shelving to v1 (or v2). I might have a go at that some point, and maybe it won't be too hard, but I can't promise I can fit that in in any particular time scale. > * viewspec (in svn info) should be hidden at compile- or run-time > > Given the release target date for 1.14 (April) we should be creating > a release branch within the next two weeks at the latest. Otherwise, > we are likely going to miss the 4-week soak window on time for April. > > Is anyone able to perform the work necessary for our experimental > features above? I do consider this topic a release blocker, so if > it isn't dealt with soon then we would either have to delay 1.14 or > decide to release with experimental features as-is. I did already make the experimental features hidden by default in "svn help"; and revealed with "-v" option. We don't necessarily need more than that. If we do want to go further in hiding them, I suggest the next step is: * create a ~/subversion/config setting to opt-in to enabling experimental features; * disable the experimental commands/options (shelving, viewspec, wc-copy-mods) unless that flag is enabled. However, I can't think of any specific reason why that's really important. Can anyone? - Julian