From nobody Sun Jan 21 18:27:04 2024 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TJ1zN1L8yz57SpN; Sun, 21 Jan 2024 18:27:12 +0000 (UTC) (envelope-from mi+t@virtual-estates.net) Received: from symbion.zaytman.com (symbion.zaytman.com [64.112.176.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "symbion", Issuer "Narawntapu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TJ1zN0h8Yz4RXy; Sun, 21 Jan 2024 18:27:11 +0000 (UTC) (envelope-from mi+t@virtual-estates.net) Authentication-Results: mx1.freebsd.org; none Received: from aldan.narawntapu (pool-100-1-252-187.nwrknj.fios.verizon.net [100.1.252.187]) by symbion.zaytman.com (8.17.1/8.16.1) with ESMTPS id 40LIR5Qt032381 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Sun, 21 Jan 2024 13:27:07 -0500 (EST) (envelope-from mi+t@virtual-estates.net) X-Authentication-Warning: symbion.zaytman.com: Host pool-100-1-252-187.nwrknj.fios.verizon.net [100.1.252.187] claimed to be aldan.narawntapu Received: from [192.168.1.10] (aldan [192.168.1.10]) by aldan.narawntapu (8.17.2/8.17.1) with ESMTP id 40LIR4rh099550; Sun, 21 Jan 2024 13:27:04 -0500 (EST) (envelope-from mi+t@virtual-estates.net) X-Authentication-Warning: aldan.narawntapu: Host aldan [192.168.1.10] claimed to be [192.168.1.10] Content-Type: multipart/alternative; boundary="------------fp5sJ79OrRTYKnsYwa0JJtBi" Message-ID: Date: Sun, 21 Jan 2024 13:27:04 -0500 List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-all@freebsd.org X-BeenThere: dev-commits-ports-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: b430a140c818 - main - net-im/purple-gowhatsapp: add WhatsApp plugin for libpurple Content-Language: en-US To: Daniel Engberg Cc: Kurt Jaeger , ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org References: <202401202030.40KKUApC045320@gitrepo.freebsd.org> <7e07375b-32bc-4778-8977-d87d6e135679@virtual-estates.net> <8ab62f5f-bb62-4633-9d1c-d7a8a8e1fc8a@virtual-estates.net> <13433172-a8cb-494c-a435-fd4d8418a2e6@virtual-estates.net> <21dcca053d36f9bec4005ffb18897f51@mail.infomaniak.com> From: "Mikhail T." In-Reply-To: <21dcca053d36f9bec4005ffb18897f51@mail.infomaniak.com> X-DCC-www.nova53.net-Metrics: aldan.narawntapu 1204; bulk rep Body=5 Fuz1=5 Fuz2=5 rep=43% X-Spam-Status: No, score=-2.9 required=23.7 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on aldan.narawntapu X-Rspamd-Queue-Id: 4TJ1zN0h8Yz4RXy X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[t]; ASN(0.00)[asn:394548, ipnet:64.112.176.0/24, country:US] This is a multi-part message in MIME format. --------------fp5sJ79OrRTYKnsYwa0JJtBi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 21.01.24 06:11, Daniel Engberg: > While neither Porters Handbook or Committers Guide say it's a > requirement it's quite strongly suggested that you do use it. Thank you, Daniel, for confirming, no actual rules were broken by my commit. > Given that all pkg-fallout mails are from Poudriere it's more or less > implied as committer to use it. I don't see the implication at all. I appreciate the fallout e-mails, but I don't see, why that makes it mandatory for me to use the same tool(s) locally. For example, the cluster builds every port on multiple hardware platforms -- for different OS-releases. Does that imply the committers also must have such multitude of different hardware/release combinations locally too? I still don't understand, why you asked me to backout... Mat's attempt at answering amounted to: "Because you broke the rules!" -- which is not a valid reason even if any rules really were broken. Clearly a personal thing... If the 37 seconds it took the cluster to fail the port is really such a drain on the resources, marking the port BROKEN would be a thing to do -- that's a one-line change, that still keeps the code available for sharing. Anyway, I think, I hacked the port into pre-fetching the additional modules using go.mk's facilities, and will be committing that shortly. It still is not perfect, because the port is a mixture of C and Go-code, but it should build fine now. Thank you for the feedback. Yours, -mi --------------fp5sJ79OrRTYKnsYwa0JJtBi Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
21.01.24 06:11, Daniel Engberg:
While neither Porters Handbook or Committers Guide say it's a requirement it's quite strongly suggested that you do use it.

Thank you, Daniel, for confirming, no actual rules were broken by my commit.

Given that all pkg-fallout mails are from Poudriere it's more or less implied as committer to use it.

I don't see the implication at all. I appreciate the fallout e-mails, but I don't see, why that makes it mandatory for me to use the same tool(s) locally. For example, the cluster builds every port on multiple hardware platforms -- for different OS-releases. Does that imply the committers also must have such multitude of different hardware/release combinations locally too?

I still don't understand, why you asked me to backout... Mat's attempt at answering amounted to: "Because you broke the rules!" -- which is not a valid reason even if any rules really were broken. Clearly a personal thing...

If the 37 seconds it took the cluster to fail the port is really such a drain on the resources, marking the port BROKEN would be a thing to do -- that's a one-line change, that still keeps the code available for sharing.

Anyway, I think, I hacked the port into pre-fetching the additional modules using go.mk's facilities, and will be committing that shortly. It still is not perfect, because the port is a mixture of C and Go-code, but it should build fine now. Thank you for the feedback. Yours,

-mi

--------------fp5sJ79OrRTYKnsYwa0JJtBi--