right procedure committing changes to core ports?

[Koichiro Iwao]

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 at FreeBSD.org>