We had a quick discussion here at the F2F with some WRS folks on the phone. We came to an agreement that the value of TIS_PATCH_VER would be reset to 1 when a rebase occurs and incremented by 1 each additional change that is made to the specfile. As part of the future "re-branding" plan we will rename TIS_PATCH_VER to STX_PATCH_VER along with the %_tis_dist/%_tis_patch_ver variables. For the current rebase in flight, what's merged is merged and what's pending should be updated to match this new understanding. Thanks for your support! Sau! On 1/7/19 7:10 AM, Scott Little wrote:
100% agree.
Scott
On 2019-01-04 9:46 a.m., Chris Friesen wrote:
When we customize an upstream package for the first time, TIS_PATCH_VER gets set to 1, then generally gets incremented on each subsequent change. Thus, prior to package upgrade TIS_PATCH_VER reflects the number of changes that were made to the upstream package. This can be used to tell at a glance how customized a given package is.
When upgrading, it's possible that some customizations are no longer applicable, while others are. Thus, I think options "a" and "e" don't make sense as they remove the "how customized is this package" meaning.
Of the options below, I think option "c" is probably the best since for an upgrade we might create a single meta-patch to add all the source patches.
I think the most accurate value would probably be "number of source patches" plus "number of meta patches that don't add/remove source patches". But we probably don't really need that level of accuracy.
Chris
On 1/4/2019 2:28 AM, An, Ran1 wrote:
Hi all I'm sending this to discuss about the rule of initial value of TIS_PATCH_VER when srpm package is upgraded. "TIS_PATCH_VER" is a counter to indicate change within a major version of the package, on which we put patches. When I upgraded srpms(related to CentOS) from CentOS 7.5 to 7.6, there are different voices about the initial value of TIS_PATCH_VER(comments on [1][2][3][4]): a). reset it to 0 b). reset to the number of STX patches remaining (source patches and meta_patches together) c). reset to the number of STX patches remaining (source patches only) d). reset to the number of STX patches remaining (meta patches only) e). case by case, better do not reset.
It is not a technical issue, but we will face it each time we upgrade packages, so which would you like to choose?
[1] https://review.openstack.org/#/c/627760/ [2] https://review.openstack.org/#/c/627750/ [3] https://review.openstack.org/#/c/627156/ [4] https://review.openstack.org/#/c/627770/
Thanks Ran