- to fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246336
- to always drop the user to a shell so he can investigate, test build, everything
- reshuffle svn vs. "All the merge work was done..." message
mandree on May 9 2020, 6:13 PM.Authored by
Adam, thanks for reviewing this.
It is mostly a convenience feature because I personally always read ydiff output (= colored svn diff) and do a make check-plist
"Blind" MFHs could be permitted in case
(I wasn't going to have the script do a "make check-plist && make package && make test" or something, or poudriere testport, which some might find necessary as future upgrade.)
Here is a scenario that I've encountered on several occasions of a fix, in variations:
If the svn merge per se doesn't throw errors, you may miss the requisite.
A practical example was mail/mailman, where a MFH of 2.1.31 or so might have changed semantics of the pkg-plist WRT @sample lines, so would violate the quarterly "no astonishment" "no breaking changes" policies as I percieve them and in my book isn't MFH worthy.
Anyways, I haven't heard back from ports-secteam@ in several days for a discussion or decision on a full 2.1.31 MFH although they normally promise to respond within 24 hours, but I guess through 2020Q2 I'll be patching mailman twice, security backport (if any further needed) onto branches/2020Q2/ and full updates onto head/...
Note that in new testing, there is one remaining corner case, and that is that the script will not detect early if the MFH was already merged earlier. It will come up with an empty merge but still ask the user if he wants to commit.