Date: Tue, 12 Mar 2019 07:50:16 +0000 From: Kubilay Kocak <koobs@FreeBSD.org> To: Koichiro Iwao <meta@FreeBSD.org> Cc: ports-committers@FreeBSD.org, python <python@FreeBSD.org> Subject: Re: right procedure committing changes to core ports? Message-ID: <0502b927-6c97-275b-64a6-91c9e6144dab@FreeBSD.org> In-Reply-To: <20190312013900.mt5s43wy7zjzoxga@icepick.vmeta.jp> References: <20190312013900.mt5s43wy7zjzoxga@icepick.vmeta.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/03/2019 1:39 am, Koichiro Iwao wrote:
> Hi,
>
> I'm willing to commit this. It fixes lang/python27 to build with
> libressl{,-devel} but it seems few people interested in that.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234568
>
> I'd appreciate if someone tell me the right procedure committing changes
> to core ports such as lang/python*, lang/perl*. I mean core ports are
> important ports that affect almost all ports users.
>
> Do I have to get someone's approval to commit it?
>
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.
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.
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
./koobs
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229223#c9
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0502b927-6c97-275b-64a6-91c9e6144dab>