From dev-return-49369-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Thu May 14 21:14:25 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 BDD29180621 for ; Thu, 14 May 2020 23:14:24 +0200 (CEST) Received: (qmail 33385 invoked by uid 500); 14 May 2020 21:14:24 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 33373 invoked by uid 99); 14 May 2020 21:14:23 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.42) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 May 2020 21:14:23 +0000 Received: from [192.168.169.22] (toroon0560w-lp130-13-70-26-27-87.dsl.bell.ca [70.26.27.87]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id AAF7A8266 for ; Thu, 14 May 2020 21:14:23 +0000 (UTC) Subject: Re: Should we continue with FDB RFC's To: dev@couchdb.apache.org References: <444717B6-2A45-4143-A045-1E37E012F9E0@apache.org> From: Joan Touzet Organization: Apache Software Foundation Message-ID: Date: Thu, 14 May 2020 17:14:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <444717B6-2A45-4143-A045-1E37E012F9E0@apache.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit The intent of the RFCs was to give people a place to look at what's being done, comment on the implementation decisions, and to form the basis for eventual documentation. I think they've been relatively successful on the first two pieces, but it sounds like they've fallen behind, especially because we have quite a few languishing PRs over in the couchdb-documentation repo. My hope had been that those PRs would land much faster - even if they were WIPs - and would get updated regularly with new PRs. Is that too onerous of a request? I agree with Adam that the level of detail doesn't have to be there in great detail when it comes to implementation decisions. It only really needs to be there in detail for API changes, so we have good source material for the eventual documentation side of things. Since 4.0 is meant to be largely API compatible with 3.0, I hope this is also in-line with expectations. -Joan "engineering, more than anything, means writing it down" Touzet On 2020-05-13 8:53 a.m., Adam Kocoloski wrote: > I do find them useful and would be glad to see us maintain some sort of “system architecture guide” as a living document. I understand that can be a challenge when things are evolving quickly, though I also think that if there’s a substantial change to the design from the RFC it could be worth a note to dev@ to call that out. > > I imagine we can omit some level of detail from these documents to still capture the main points of the data model and data flows without needing to update them e.g. every time a new field is added to a packed value. > > Cheers, Adam > >> On May 13, 2020, at 5:29 AM, Garren Smith wrote: >> >> Hi All, >> >> The majority of RFC's for CouchDB 4.x have gone stale and I want to know >> what everyone thinks we should do about it? Do you find the RFC's useful? >> >> So far I've found maintaining the RFC's really difficult. Often we write an >> RFC, then write the code. The code often ends up quite different from how >> we thought it would when writing the RFC. Following that smaller code >> changes and improvements to a section moves the codebase even further from >> the RFC design. Do we keep updating the RFC for every change or should we >> leave it at a certain point? >> >> I've found the discussion emails to be really useful way to explore the >> high-level design of each new feature. I would probably prefer that we >> continue the discussion emails but don't do the RFC unless its a feature >> that a lot of people want to be involved in the design. >> >> Cheers >> Garren >