Re: git: 34b444edf631 - main - devel/icu: Revert unrelated changes in previous commit

From: Daniel Engberg <diizzy_at_FreeBSD.org>
Date: Fri, 28 Feb 2025 19:24:53 UTC
On 2025-02-28 07:53, Po-Chuan Hsieh wrote:
> On Fri, Feb 21, 2025 at 8:27 AM Daniel Engberg <diizzy@freebsd.org 
> <mailto:diizzy@freebsd.org>> wrote:
> 
>     The branch main has been updated by diizzy:
> 
>     URL: https://cgit.FreeBSD.org/ports/commit/?
>     id=34b444edf6319efbf1ee2c8b75e3e4db1f72378c <https://
>     cgit.FreeBSD.org/ports/commit/?
>     id=34b444edf6319efbf1ee2c8b75e3e4db1f72378c>
> 
>     commit 34b444edf6319efbf1ee2c8b75e3e4db1f72378c
>     Author:     Daniel Engberg <diizzy@FreeBSD.org>
>     AuthorDate: 2025-02-20 23:40:38 +0000
>     Commit:     Daniel Engberg <diizzy@FreeBSD.org>
>     CommitDate: 2025-02-20 23:40:42 +0000
> 
>          devel/icu: Revert unrelated changes in previous commit
> 
>          Remove unrelated and undocumented changes made in commit
>          312c3df64b879c24fafa08ddfcef40b3069be399
> 
> 
> ARE YOU A COMMIT LOG POLICE?
> 
> I consider this to be hostile behavior. I am quite certain this is 
> directed at me. Please STOP this behavior.
> 
> 
>          Approved by:    portmgr (blanket)
> 
> 
> To portmgr:
> 
> Could you please clarify if it is covered by the blanket?
> Thanks.
> 
>     ---
>       devel/icu/Makefile | 4 ++--
>       1 file changed, 2 insertions(+), 2 deletions(-)
> 
>     diff --git a/devel/icu/Makefile b/devel/icu/Makefile
>     index e3b4960e7d7a..911f9bce54cf 100644
>     --- a/devel/icu/Makefile
>     +++ b/devel/icu/Makefile
>     @@ -35,7 +35,7 @@ WRKSRC=               ${WRKDIR}/icu/source
>       ICUMAJOR=      ${PORTVERSION:C/\..*//}
>       PLIST_SUB+=    ICUMAJOR=${ICUMAJOR} ICUVER=${PORTVERSION:C/r.?/1/}
> 
>     -.if !defined(PKGNAMESUFFIX)
>     +.ifndef PKGNAMESUFFIX
>       post-install:
>              @${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/g* \
>                      ${STAGEDIR}${PREFIX}/bin/*conv \
>     @@ -47,6 +47,6 @@ post-install:
>       # Filename varies by endianness: icudt<major>b.dat vs.
>     icudt<major>l.dat
>              @(cd ${STAGEDIR}${PREFIX} && ${ECHO_CMD} \
>                      ${DATADIR_REL}/${PORTVERSION:C/r.?/1/}/icudt*.dat
>      >>${TMPPLIST})
>     -.endif # !defined(PKGNAMESUFFIX)
>     +.endif # PKGNAMESUFFIX
> 
>       .include <bsd.port.mk <http://bsd.port.mk>>
> 

Hi,

Given that I recently worked on and committed an update I did keep an 
eye at it for any reports. Given that the git commit log says 
"devel/icu: Update WWW" with no further information regarding other 
changes or  any testing one would assume that commit message would at 
least somewhat correlate to actual changes otherwise be a honest mistake 
unless you are to make the assumption that commit messages barely needs 
to be related or "fill in the gaps" yourself. In addition to that 
https://docs.freebsd.org/en/articles/committers-guide/#ports-qa-misc-blanket-approval 
also says "Trivial and tested build and runtime fixes." Given that no 
information was provided it falls under not tested as one could view it 
as accidental. If that's an unreasonable level of expectation and 
considered hostile that needs to be clarified in either Porters Handbook 
or Committers Guide.

Given we're already on the topic I would expect portmgr@/conduct@ to 
address 
https://cgit.freebsd.org/ports/commit/?id=121fcc3c22e20c70a2bf1ad6281857757c8773e4 
appropriately. One would expect something like a mail saying something 
along the lines of: "Sorry, I was in a hurry and didn't provide adequate 
information" or at least "Hey, why didn't get this get committed?". I 
expect an public apology and at least a warning given that this behavior 
is unacceptable.

As sunpoet once again didn't provide adequate information/any details of 
testing/explanation to changes and I didn't want to spend more time do 
more testing I committed my tested patch to move things forward given 
that the PR already had been open for months (previous version). I also 
can't find any mentioned preferences in Porters Handbook about this.

Best regards,
Daniel