right procedure committing changes to core ports?

[Matthew Seaman]

On 12/03/2019 07:50, Kubilay Kocak wrote:
> 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
> 

For something with as many dependencies as python-2.7 you should also be
contacting portmgr (well: Antoine) about whether an exp-run will be
necessary.

	Cheers,

	Matthew


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-python/attachments/20190312/1a606c95/attachment.sig>