Date: Tue, 12 Mar 2019 22:24:01 +0900 From: Koichiro Iwao <meta@FreeBSD.org> To: Kubilay Kocak <koobs@FreeBSD.org> Cc: ports-committers@FreeBSD.org, python <python@FreeBSD.org> Subject: Re: right procedure committing changes to core ports? Message-ID: <20190312132401.u2aujcx5ajcsvca6@icepick.vmeta.jp> In-Reply-To: <0502b927-6c97-275b-64a6-91c9e6144dab@FreeBSD.org> References: <20190312013900.mt5s43wy7zjzoxga@icepick.vmeta.jp> <0502b927-6c97-275b-64a6-91c9e6144dab@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <meta@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190312132401.u2aujcx5ajcsvca6>