From dev-return-111461-archive-asf-public=cust-asf.ponee.io@ofbiz.apache.org Wed Aug 29 11:53:57 2018 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 [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 2CD15180657 for ; Wed, 29 Aug 2018 11:53:57 +0200 (CEST) Received: (qmail 77895 invoked by uid 500); 29 Aug 2018 09:53:56 -0000 Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ofbiz.apache.org Delivered-To: mailing list dev@ofbiz.apache.org Received: (qmail 77883 invoked by uid 99); 29 Aug 2018 09:53:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2018 09:53:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 2CEFA180A7D for ; Wed, 29 Aug 2018 09:53:55 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id k1hkMXleG3w0 for ; Wed, 29 Aug 2018 09:53:53 +0000 (UTC) Received: from smtp.nfrance.com (smtp-6.nfrance.com [80.247.225.6]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 2F0F25F180 for ; Wed, 29 Aug 2018 09:53:53 +0000 (UTC) Received: from [192.168.1.2] (183.90.14.81.rev.sfr.net [81.14.90.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.nfrance.com (Postfix) with ESMTPSA id 08FD511282B for ; Wed, 29 Aug 2018 11:53:51 +0200 (CEST) Subject: Re: Policy on commit To: dev@ofbiz.apache.org References: <1672b261-3740-3839-28b4-009df4cf01ae@les7arts.com> From: Jacques Le Roux Organization: Les Arts Informatiques Message-ID: Date: Wed, 29 Aug 2018 11:53:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1672b261-3740-3839-28b4-009df4cf01ae@les7arts.com> Content-Type: multipart/alternative; boundary="------------D6162FD1711E1B9B970645DF" Content-Language: en-GB X-Scanned-By: MIMEDefang 2.78 on 80.247.225.6 --------------D6162FD1711E1B9B970645DF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit oOps, I missed to finish a sentence... amended inline... Le 27/08/2018 à 10:15, Jacques Le Roux a écrit : > Hi Michael, All, > > First, thank you Michael for your effort in trying to clarify what to discuss in dev ML (this has already been , when to revert a commit, and I'll > add relations with Jiras status. (this has already been discussed and agreed in the past) > I know it's important for you to correctly deliver the information about OFBiz activity in the monthly blog post > > My goal here is to decide if we should write best practices for that in > https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices > > > And if yes, to clearly write them. This to avoid future confusion and conflicts in the community about these subjects. > > Before beginning on that, I have already collected some information, I'd like to be sure we all agree about doing so. Then, if we agree we can begin > to discuss what to write... > > Thanks for your attention > > Jacques > > > Le 19/08/2018 à 11:28, Michael Brohl a écrit : >> I have not the time to dig into the specific details right now so will just give my thoughts on the process in general because of the citations: >> >> 1. we have to distinguish between (a) completely new functionality or major refactorings and (b) the enhancement of functionality which is already >> in the code base >> >> 2. for (a), we should first have consenus that we want the proposed solution and we should look for a complete, well designed and carefully tested >> solution before the first commit will be done. This is to prevent the introduction of new problematic code. >> >> 3. for (b), I think every improvement of existing code/functionality helps and should be committed if there are no flaws in the design or technical >> solution and it does not break existing funtionality. of course, it should be complete within the *scope* of the improvement. >> >> 4. if the solution for (b) does not cover other wishes or things which could be enhanced also, this would be no reason to not commit the >> improvement. If people have further requirements, they can provide concepts and solutions/patches anytime to make things better. >> >> In this case, for me it is important if Suraj's commit >> >> a. breaks anything? >> >> b. is vetoed by other committers in view of code quality or design flaws? >> >> If none of these questions get a "yes", then I see no reason to revert. >> >> If you have additional requirements, you are encouraged to provide solutions or concepts for them. >> >> Thanks, >> >> Michael Brohl >> ecomify GmbH >> www.ecomify.de > > --------------D6162FD1711E1B9B970645DF--