Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A06AA10B51 for ; Sun, 5 Jan 2014 10:13:49 +0000 (UTC) Received: (qmail 38833 invoked by uid 500); 5 Jan 2014 10:13:47 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 38573 invoked by uid 500); 5 Jan 2014 10:13:44 -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 38563 invoked by uid 99); 5 Jan 2014 10:13:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Jan 2014 10:13:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com designates 209.85.128.45 as permitted sender) Received: from [209.85.128.45] (HELO mail-qe0-f45.google.com) (209.85.128.45) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Jan 2014 10:13:36 +0000 Received: by mail-qe0-f45.google.com with SMTP id 6so16935482qea.4 for ; Sun, 05 Jan 2014 02:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=rdEoYXd9X9cXs+Y3G8EYDw5vwBqywSSrJ7QGl+plIB8=; b=l7Qr3431HROoa/nwmPnyynuGP8QVYi0MC5+EFwP1TDk5+TvorNQz4g6/cjASlwLkgm E0SsNRCruj8TbDPeSWDpm8qAYla7oo7Me6aV8Q48PmvhKSvtH9CozkYuJLuVYI7EmKlo +tzOC5mj49VS3n3MCI7Tcj5xY1SBOv+0uk7DyAvpx7/fQ3Lb+ZloqDdO0DEA8UvkMkIM LFcBVrqnyq7j/3GQFvBWPE8Vy9T9Qe9yUSBSz66DyGg62rnnVymFnNZ9d3KcAOIINDI/ G64tH1eclNIh6aEVFKV6X4D5NfarNarVrkU017GS1rgS5Qc8MkZNjdDWsNodhRg3dJOg hcgA== X-Received: by 10.224.88.202 with SMTP id b10mr166204350qam.85.1388916796040; Sun, 05 Jan 2014 02:13:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.56.73 with HTTP; Sun, 5 Jan 2014 02:12:55 -0800 (PST) In-Reply-To: References: From: Benoit Chesneau Date: Sun, 5 Jan 2014 11:12:55 +0100 Message-ID: Subject: Re: [PROPOSAL] tag our commits To: "dev@couchdb.apache.org" Content-Type: multipart/alternative; boundary=001a11c285b84029e204ef3664a1 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c285b84029e204ef3664a1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 6:45 PM, Noah Slater wrote: > Consolidating my replies to a single email so as to limit mail churn. :) > > On 4 December 2013 18:33, Benoit Chesneau wrote: > > > Having tags force naturally people to[...] > > Having tags force people to[...] > > > If the system if it's optional it lost any interest. People that don't > want > > to use it won't use it and we will stay with the same soup and > meaningless > > commit messages forcing people to read the full change to figure. > > Guidelines do not force anything. If something is confusing or people > don't like it, it will be ignored. > If you ignore a guideline then it should be discussed rather than being ignored. By forcing here I am just expecting that people really take care about guidelines and their spirit and then pay attention to it even if they don't follow them strictly. > > > a tag should be related to the feature it patches > > I think this sounds like a good idea. But we should recommend that > people tag the one-line comment with any major system that is > effected. But it should not be compulsory to do so. > Actually it should be good that we tag the commits. I can still see a lot of commits that force me to look at the code because the description is vague or lack of the context to see if I should backport it in a test branch or not. Which is to say less a big time killer. I agree that sometimes a tag is too much restrictive anyway so it may be just a matter of having for rule to make the first line really descriptive (a tag most of the time will figure what is the comment context). If we are speaking of guideline I really think that a code should go in a review branch before landing in the master so eventually the comment could be corrected and some patches rebased. It's really painful to handle a change is that is fixing a change that was fixing a change that was fixing another.... Each time you backport it (for tests or productions) it imply that you relaunch tests. And I am pretty sure that most of the time such commits could be skipped in the master if the code was reviewed. > >> And let's say we want to accept a pull request on Github that adds foo > >> atomically. Are we really going to send the person away and ask them > >> to decompose the commit into many commits, each one with a tag? > >> > > > > yes. This is a good practice. > > This is the opposite of every pull request I've ever seen. (Which is, > admittedly, not many.) > You can see on github that a lot of PR are composed of many commits, most of the time corresponding to one change that can affect the code deeply. It is really a good practice to separate commits in an atomic way, so a serious review can be done so that the accepted changes (if any) don't imply to have to review another big patch. - benoit --001a11c285b84029e204ef3664a1--