Exclusion on Component Doc-spec/BRS. This should work even if the Fix version is 37.
Solution: Use Resolution Fixed non-Repo (no fix needed)
Exclusions aren’t working (When I run the Commit Checker and go to the URL, it’s actually getting a lot more hits on things that were already on the Exclusion list)
Example Macao(MO) territory translation in Nepali
Solution: Update Commit checker (Steven, Maybe because we are using the ICU version rathe rather than the version that was modified for CLDR)
Exclude Component Charts
Solution: Include Component Chart in the exclusion list
OK, i think i may be closing on a workable algorithm here.
(1.) step 1 is to find the ‘merge base' of the OLD release. Given the input arguments --rev-range release-37..origin/maint/maint-38 we split at the .. (note space instead of .. ) and run:
Aha! 696… is the hollow diamond in the above graph!
(2.) Now we can walk the tree 6962fb4ad25ce89645211c13bbd2cb1f52a62861… `origin/maint/maint-38` ( AKA: hollow diamond…white square). This will NOT include 696… but WILL include 5ab4 ( and all other commits leading up to the release branch.) (Side question: should we use “maint-37” instead of “release-37”? Answer: No, I think we should use “release-37 because that is what’s released. . However, this would break down if there was a 37.1 … have to come back to that and may need multiple arguments. )
(3) In walking the above tree, we collect commits that ARE cherry picks in maint-37 that are already on the path leading up to maint-38…
(4) Then, we can exclude such commits, from the “Jira not found”. (perhaps with a summary).
Still trying to understand git cherry -v - when I first ran it, it made sense how I’d integrate, but I can’t reproduce my earlier test. It may be that it will actually do steps 2-3 for me.
At least, I think for the first time I have a concrete plan for how step 2 needs to be done, so I can evaluate whether git cherry does it.
Okay, i finally have the command:
This will print out a list of commits, since 37 was cut, but which are already backported to the 37 maint branch. These commits can then be excluded from expecting them to be in v38. For example, in our graph, f95e9995b3a35dcc799cedcc44ab3362825c5589 is in the list and thus would be excluded.
“merge-base” here is used to calculate the 6962f… commit (the hollow diamond).
^ I’m making progress on above.
(Side note: I see that started down the path of managing cherry picks in the commit checker last year for ICU in ICU-20444
: the commit is not recognized as a cherry pick, and indeed it is different from its cherry pick upstream for example at line which is not present (unchanged) in the original fd906e896df8f8179b87d577776f58e103ca7c44
Not a complaint - this is why cherry picks are a manual process.
I think I can also check the commit messages for “Cherry pick of _______” but I’d probably want to list those in the tool - just so that they can be manually checked as well, because we should be aware that there is such a divergence.
sent email to CLDR-TC subject “commit checker and cherry picks” with an update and the then-latest checker report https://cldr-smoke.unicode.org/cldrcc/CLDR-Report-2020-10-23-v38-4c8af0e685.html —
moving this ticket back to Reviewing.
don’t think there are any outstanding issues here.