From owner-freebsd-python@freebsd.org Tue Mar 12 13:24:07 2019 Return-Path: Delivered-To: freebsd-python@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75CF71530E23 for ; Tue, 12 Mar 2019 13:24:07 +0000 (UTC) (envelope-from meta@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E97AE8E1C7 for ; Tue, 12 Mar 2019 13:24:06 +0000 (UTC) (envelope-from meta@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A3D321530E22; Tue, 12 Mar 2019 13:24:06 +0000 (UTC) Delivered-To: python@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FBC71530E21 for ; Tue, 12 Mar 2019 13:24:06 +0000 (UTC) (envelope-from meta@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2255C8E1C3; Tue, 12 Mar 2019 13:24:06 +0000 (UTC) (envelope-from meta@FreeBSD.org) Received: from icepick.vmeta.jp (unknown [IPv6:2405:6586:2280:1200:3071:4ffc:cb02:4094]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: meta/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id B03B01E6BE; Tue, 12 Mar 2019 13:24:04 +0000 (UTC) (envelope-from meta@FreeBSD.org) Date: Tue, 12 Mar 2019 22:24:01 +0900 From: Koichiro Iwao To: Kubilay Kocak Cc: ports-committers@FreeBSD.org, python Subject: Re: right procedure committing changes to core ports? Message-ID: <20190312132401.u2aujcx5ajcsvca6@icepick.vmeta.jp> References: <20190312013900.mt5s43wy7zjzoxga@icepick.vmeta.jp> <0502b927-6c97-275b-64a6-91c9e6144dab@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0502b927-6c97-275b-64a6-91c9e6144dab@FreeBSD.org> X-Operating-System: FreeBSD 12.0-STABLE amd64 User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: 2255C8E1C3 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.91)[-0.910,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 13:24:07 -0000 Kubilay, thanks for your reply. On Tue, Mar 12, 2019 at 07:50:16AM +0000, Kubilay Kocak wrote: > > Hi Koichiro, > > There's a few distinct issues in this: > > 1) Approval for python@ ports, in general: Yes they require python@ approval > as we're on the hook for QA/regressions/maintainership. > > For non-core ports (other than lang/python*, setuptools and a few other > important ports) commit by maintainer timeout *with complete QA* is of > course fine. > > Unfortunately there's no way to codify a 'core/non-core' or other useful > policy/maintainership distinctions by way of a MAINTAINER_POLICY or similar, > so the difference between 'this port is super important and requires extra > eyes/review' and 'we're just a fallback/defacto maintainer' is not apparent > or obvious. I expect this is a similar issue in other major porting teams > (gnome, kde, ruby, et al) too. I have same opinion this. I'm a little bit confused because of this. Ideally, these two cases should be distincted. It might be a whole ports framework & community issue. > 2) The python build system is *notoriously* sensitive to changes, > particularly with apparently simple CFLAGS, *FLAGS, environment changes. > This is *especially* the case with *ssl library support, which a comment of > yours in a separate but related issue testifies to: "The patch fixes build > with libressl, libressl-devel, openssl111 but breaks openssl." [1] > > 3) Python build/upstream code fixes, especially for library support really > need to 'go upstream' by default. It may be the case that this has already > been solved up stream. I have seen libressl issues reported upstream, but I > have not followed their status or resolution. There's no indication in the > issue so far of that kind of analysis. > > It's much easier/faster to review and approve a commit by someone not on the > python team if there's been a upstream bug report and commit merged to > address the issue. We've worked very hard to reduce our diffs to upstream > and, we still have a way to go. Generally, upstream first policy and reducing ports local patches are good ideas. We should do that as far as possible. However, Python 2.7 is reaching EoL. I concern upstream is not very active. Try before concern? Indeed. > 4) This specific issue (building with libressl): the report and patch is for > 2.7, but there's no information provided for whether or not 3.x requires the > same treatment, or if there are similar (exactly the same?, slightly > different?) issues in those branches, and across libressl versions. > > Given we have multiple branches of Python to support at any one time, its > especially important to address issues as consistently and completely across > all of those versions, where relevant, as possible, with complete and > extensive QA. Committing changes is easy, understanding, analysing, ensuring > a complete and correct change proposal is the difficult part. > > Happy to discuss this with you further on IRC, #freebsd-python @ freenode Okay, I hardly be online on IRC but I'll join che channel when I have doubts. -- meta