기여 목록 / 8496107
[Commerce] Remove the expired Commerce.Heuristics.* histograms
BrowsercleanupMerged
커머스 휴리스틱 데이터(장바구니·결제 페이지 판별 패턴 등)를 어디서 가져왔는지 기록하던 Commerce.Heuristics.*Source 히스토그램 6개와, 그것만 기록하던 helper 클래스를 통째로 제거했습니다. 여섯 개 모두 2023~2024년에 만료돼 이미 기록되지 않는 상태였습니다. 8파일 −223. 코드와 histograms.xml 양쪽 OWNER인 mdjones@의 +1 뒤, 커머스 히스토그램 정리를 진행 중이던 meiliang@가 두 번째로 승인했고, mdjones@가 CQ를 돌려 2026-10-03에 머지됐습니다(308a20785a379).
문제 설명
- crbug 없음 (자체 발굴)
CommerceHeuristicsDataMetricsHelper는 휴리스틱 데이터가 컴포넌트 업데이터·리소스·Finch 파라미터 중 어디서 왔는지를Commerce.Heuristics.{CartExtractionScript,CheckoutURLGeneralPattern,MerchantName,PartnerMerchantPattern,ProductIDExtractionPattern,SkipProductPattern}Source로 기록했습니다.histograms.xml에서 여섯 개 모두 2023-02-19 ~ 2024-07-21에 만료됐고expired_intentionally표시도 없었습니다. 히스토그램 문서는 만료된 히스토그램의 기록 코드를 죽은 코드로 보고 지우라고 합니다.- 게다가 기록 함수 6개 중 4개는 ChromeCart를 삭제할 때(crrev.com/c/5932823, crrev.com/c/5990619) 이미 호출처가 사라져 있었습니다.
해결 내용
- helper 클래스(
commerce_heuristics_data_metrics_helper.{h,cc})와 BUILD.gn 항목을 지웠습니다. - 남아 있던 호출 4곳(
commerce_feature_list.cc의GetRulePartnerMerchantPattern()2곳,commerce_heuristics_provider.cc의GetVisitCheckoutPattern()2곳)과 include를 지웠습니다. 어떤 패턴을 고르는지는 그대로입니다. CommerceFeatureListTest에서 히스토그램 버킷을 확인하던 4곳과HistogramTester멤버를 지웠습니다. 패턴이 어느 출처에서 왔는지는 기존 URL 매칭 검사로 계속 확인됩니다.tools/metrics/histograms/metadata/commerce/histograms.xml의 여섯 항목과, 이 히스토그램들만 쓰던CommerceHeuristicsDataSourceenum을 지웠습니다.
발굴 과정
09-29 «만료된 히스토그램 기록 코드» 스캔 결과를 파일 단위로 묶어 보니, 이 helper 파일은 기록하는 히스토그램이 전부 만료된 파일이었습니다. 살아 있는 계측을 건드리지 않으니 리뷰가 단순하고, 클래스를 통째로 지울 수 있었습니다. git log -S로 기록 함수의 호출처가 언제 사라졌는지 추적해 ChromeCart 삭제 CL 두 개를 근거로 붙였습니다. 리뷰어는 components/commerce와 commerce 히스토그램 메타데이터 양쪽 OWNER인 mdjones@ 한 명으로 정했습니다. OSSCA #591.
테스트 방법
components_unittests증분 빌드 12스텝 24초components_unittests --gtest_filter='CommerceFeatureListTest.*:CommerceHeuristicsDataTest.*'31/31 통과- presubmit 0 경고, 히스토그램
pretty_print.py·validate_format.py통과 - 같은
histograms.xml에 09-24 이후 머지된 CL 5개 위로 3-way 병합 시뮬레이션 — 충돌 0
배운 점
- 히스토그램을 지울 때는 코드 OWNERS뿐 아니라
tools/metrics/histograms/metadata/<디렉터리>/OWNERS도 확인해야 합니다. 같은 날 HA(8481931)가 리뷰어 두 명의 LGTM을 받고도metadata/net/histograms.xmlowner 승인이 없어 제출되지 못하는 걸 보고, 이 CL은 양쪽 OWNER인 한 명을 골랐습니다. - 삭제된 헤더를 가리키는
chrome/renderer/DEPS규칙처럼 다른 디렉터리 OWNER가 필요한 정리는 후속 CL로 분리하면 리뷰어를 한 명으로 유지할 수 있습니다. - 두 번째 리뷰어는 같은 영역을 이미 정리하고 있는 사람(«[histogram-cleanup]» 프로젝트의 meiliang@)을 고르니 하루 안에 승인이 왔습니다. 활동이 뜸한 OWNER보다 그 코드를 최근에 만진 사람이 빠릅니다.